Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU  8 Jun 89 13:55:11 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 264692; 8 Jun 89 13:54:53 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 8 Jun 89 13:49:23 EDT
Message-Id: <2822320478-4024841@RTS-8>
Sender: ziggy@RTS-8.LCS.MIT.EDU
Date: Thu, 8 Jun 89  13:54:38 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt
Subject: Proposed Changes to R3.95RS

Missing from Will's list were the following [i.e., I hereby propose them]
in decreasing severity (increasing flammability):

 [] Fix bug in Number grammar: it does not generate for example .34
    Fix:  <decimal 10> --> ... | . <digit 10>+ #* <suffix>
                                             ^
                                             `--- NB

 [] Add @ to the list of extended alphabetics.  Note that this does not
    generate ambiguity for ,@ since [i] the @ must immediately follow the ,
    [Ref:4.2.6] and [ii] , is not an extended alphabetic.  [Note: I notified
    Jonathan about this quite a while ago and he assured me that @'s absence
    was a mere oversight].

 [] CHAR->INTEGER & INTEGER->CHAR stipulated as ``one-to-one'' ... I would
    prefer the term ``injective''.  I am anal.  Maybe use both but
    parenthesize one.

 [] For that matter, isn't what you are really trying to stipulate now that
    CHAR->INTEGER and INTEGER->CHAR be functional inverses? If so, I suggest
    changing ``Given an exact integer that is the image of a character under
    CHAR->INTEGER, INTEGER->CHAR returns a character'' to:
                            ``...returns that character.''

 [] Finally, doesn't CHAR->INTEGER make more embarrassing the fact that we
    consistently call integer stuff INTEGER while we uniformly (but
    inconsistently) call character stuff CHAR.  Wouldn't we all sleep better
    with CHARACTER->INTEGER and so on...  Or maybe some would prefer
    INT->CHAR, PROC?, BOOLE?  After all, implementations can always add the
    shorter (or longer) forms to their standard library.
								Anally Yours,
								   ~Ziggy


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jun 89 08:03:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11393;
          5 Jun 89 7:55 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00870; Mon, 5 Jun 89 07:56:02 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Mon, 5 Jun 89 07:53:32 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA07894; Mon, 5 Jun 89 07:53:55 EDT
Posted-Date: Mon, 5 Jun 89 07:54:20 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA10590; Mon, 5 Jun 89 07:54:20 EDT
Date: Mon, 5 Jun 89 07:54:20 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8906051154.AA10590@huxley.mitre.org>
To: rrrs-authors%mc.lcs.mit.edu@zurich.ai.mit.edu
In-Reply-To: William Clinger's message of Fri, 2 Jun 89 16:00:32 PDT <8906022300.AA21869@fog.cs.uoregon.edu>
Subject:  [ramsdell: truth of (), etc...]
Reply-To: ramsdell@mdf.mitre.org


Will Clinger wrote:

   For what it's worth, here are the two reasons that I prefer the existing
   semantics:

     1.  I find that it is easier to understand code when I can assume that
	 the order of definitions doesn't matter.  That way I can read the
	 definitions in any order.  This is a special case of the general
	 principle that a more declarative semantics makes programs easier
	 to understand.

The point is that under the current semantics, the order in which you
write top level definitions does matter.  No matter what is in R^nRS,
I suspect most Scheme users will attempt to understand internal
definitions just as they do top level ones: if a lambda expression is
being named, order does not matter, otherwise the order in which
expressions are named does matter.  Note a Scheme user can explicitly
declare that the order of definition does not matter by using the
LETREC syntax.  Given the existence of LETREC, I find it hard to
justify having the meaning of the DEFINE syntax depend on the
environment in which it is used.  The principle that a more
declarative semantics makes programs easier to understand is a sound
one.  In this case, giving DEFINE a uniform semantics conflicts with
this principle.  I vote for uniformity.

     2.  (This reason is pretty weak.)  For the compiler writer, I think the
	 freedom to rearrange definitions makes closure analysis a little
	 simpler when procedure definitions are mixed with definitions of
	 variables containing non-procedure values.

I agree that this reason is pretty weak.

   Note that I am very strongly proposed to another proposal that was
   advanced some time ago, which would require a rather complicated and
   unintuitive order of evaluation that could only be specified in terms
   of a static dependency analysis.

The proposal to which Will refers is a proposal I made to do a
dependency analysis on definitions.  As a result of various
conversations, I no longer support this and proposes sending it to
Lotus so they can patent the idea and spend more money on lawyers.

John


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Jun 89 08:36:43 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17884;
          2 Jun 89 19:02 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00875; Fri, 2 Jun 89 19:02:57 EDT
Return-Path: <@mist.math.uoregon.edu:will@fog.cs.uoregon.edu>
Received: from mist.math.uoregon.edu (mist.math.uoregon.edu) by ZURICH.AI.MIT.EDU; Fri, 2 Jun 89 19:00:30 edt
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Fri, 2 Jun 89 16:00:40 PDT
Received: by fog.cs.uoregon.edu; Fri, 2 Jun 89 16:00:32 PDT
Date: Fri, 2 Jun 89 16:00:32 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8906022300.AA21869@fog.cs.uoregon.edu>
To: ramsdell%linus.mitre.org@relay.cs.net, 
    rrrs-authors%mc.lcs.mit.edu@zurich.ai.mit.edu
Subject: Re:  [ramsdell: truth of (), etc...]

John Ramsdell wrote:
    Is there any support for the idea of giving internal definitions the
    same semantics as top level definitions?  I have yet to hear a strong
    argument as to why they should mean something different.  Maybe R4RS
    should explain the decision it describes.

    <BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
      ((lambda (<I> ...)
         (set! <I> <EXP>)
         ...
         <SEQUENCE>)
       <UNDEFINED> ...)

(In other words, the proposal is to require that internal definitions be
evaluated from left to right, with each succeeding definition allowed to
use variables defined before it.)

Although I prefer the existing semantics, I would not be strongly opposed
to changing it to require that definitions be evaluated in order.  I suspect
that most implementations currently do this anyway for compatibility with
the Abelson&Sussmans book (where a bug makes one of the larger programs
depend on left to right evaluation).

For what it's worth, here are the two reasons that I prefer the existing
semantics:

  1.  I find that it is easier to understand code when I can assume that
      the order of definitions doesn't matter.  That way I can read the
      definitions in any order.  This is a special case of the general
      principle that a more declarative semantics makes programs easier
      to understand.
  2.  (This reason is pretty weak.)  For the compiler writer, I think the
      freedom to rearrange definitions makes closure analysis a little
      simpler when procedure definitions are mixed with definitions of
      variables containing non-procedure values.

Note that I am very strongly proposed to another proposal that was
advanced some time ago, which would require a rather complicated and
unintuitive order of evaluation that could only be specified in terms
of a static dependency analysis.

Peace, Will

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Jun 89 03:28:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04775;
          2 Jun 89 15:20 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA06757; Fri, 2 Jun 89 15:19:24 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Fri, 2 Jun 89 15:15:37 edt
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906021915.AA02759@ZURICH.AI.MIT.EDU>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Tue, 30 May 89 17:08:52 PDT <8905310008.AA09136@fog.cs.uoregon.edu>
Subject: another change for R4RS; peek-char
Reply-To: cph@zurich.ai.mit.edu

   Date: Tue, 30 May 89 17:08:52 PDT
   From: William Clinger <will@fog.cs.uoregon.edu>

   One person has objected, strongly, to making list-ref and list-tail
   essential.  Does anyone wish to counter by explaining just why it
   is essential that these procedures be essential?

The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):

    6.1  Procedures to be deleted from the standard.

    Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
    SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
    STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!.  Since
    LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
    author's agreement to change them to essential.

This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS.  If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.

I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Jun 89 01:41:37 EDT
Received: from MBUNIX.MITRE.ORG by mintaka.lcs.mit.edu id aa07072;
          2 Jun 89 13:34 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA08274; Wed, 31 May 89 09:31:25 EDT
Posted-Date: Wed, 31 May 89 09:31:40 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA06399; Wed, 31 May 89 09:31:40 EDT
Date: Wed, 31 May 89 09:31:40 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8905311331.AA06399@huxley.mitre.org>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Tue, 30 May 89 17:08:52 PDT <8905310008.AA09136@fog.cs.uoregon.edu>
Subject: truth of (), etc...
Reply-To: ramsdell@mdf.mitre.org


I strongly agree with the following change to the truth value of ():

   Sections 3.2 (True and false), 4.1.5 (Conditionals),
   and 6.1 (Booleans).  It will be explicitly unspecified whether
   the empty list counts as true or as false in a conditional
   expression.

   ----------------------------------------------------------------

We need peek-char; remember JAR's point that it should be possible to
write READ in Scheme.  The note in R3.95RS looks good.

   ----------------------------------------------------------------

On macros,

  Chris Hanson deserves great credit for developing a macro facility
  along the lines envisioned at Snowbird, but the well-specified part
  of it does not seem to be sufficiently powerful.  I gather that the
  system itself is adequately powerful, provided we accept that "the
  implementation is the specification", but we certainly don't want to
  accept that.

Is there anything written that would explain the current situation in
more detail?

   ----------------------------------------------------------------

Is there any support for the idea of giving internal definitions the
same semantics as top level definitions?  I have yet to hear a strong
argument as to why they should mean something different.  Maybe R4RS
should explain the decision it describes.

<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
  ((lambda (<I> ...)
     (set! <I> <EXP>)
     ...
     <SEQUENCE>)
   <UNDEFINED> ...)

John

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jun 89 23:07:02 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08412;
          2 Jun 89 11:03 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00306; Fri, 2 Jun 89 11:03:57 EDT
Received: from mitre.arpa (mitre.arpa) by ZURICH.AI.MIT.EDU; Fri, 2 Jun 89 06:49:45 edt
Organization: The MITRE Corp., Washington, D.C.
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA03417; Fri, 2 Jun 89 06:37:51 EDT
Posted-Date: Fri, 2 Jun 89 06:38:12 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA08013; Fri, 2 Jun 89 06:38:12 EDT
Date: Fri, 2 Jun 89 06:38:12 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8906021038.AA08013@huxley.mitre.org>
To: rrrs-authors%mc.lcs.mit.edu@zurich.ai.mit.edu
Subject: [ramsdell: truth of (), etc...]

Broken network connection again.  Here is the forwarded message:

Date: Wed, 31 May 89 09:31:37 EST
From: ramsdell
To: rrrs-authors@mc.lcs.mit.edu
In-reply-to: William Clinger's message of Tue, 30 May 89 17:08:52 PDT <8905310008.AA09136@fog.cs.uoregon.edu>
Subject: truth of (), etc...
Reply-to: ramsdell@mitre.org


I strongly agree with the following change to the truth value of ():

   Sections 3.2 (True and false), 4.1.5 (Conditionals),
   and 6.1 (Booleans).  It will be explicitly unspecified whether
   the empty list counts as true or as false in a conditional
   expression.

   ----------------------------------------------------------------

We need peek-char; remember JAR's point that it should be possible to
write READ in Scheme.  The note in R3.95RS looks good.

   ----------------------------------------------------------------

On macros,

  Chris Hanson deserves great credit for developing a macro facility
  along the lines envisioned at Snowbird, but the well-specified part
  of it does not seem to be sufficiently powerful.  I gather that the
  system itself is adequately powerful, provided we accept that "the
  implementation is the specification", but we certainly don't want to
  accept that.

Is there anything written that would explain the current situation in
more detail?

   ----------------------------------------------------------------

Is there any support for the idea of giving internal definitions the
same semantics as top level definitions?  I have yet to hear a strong
argument as to why they should mean something different.  Maybe R4RS
should explain the decision it describes.

<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
  ((lambda (<I> ...)
     (set! <I> <EXP>)
     ...
     <SEQUENCE>)
   <UNDEFINED> ...)

John




Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 20:13:55 EDT
Received: from mist.math.uoregon.edu by mintaka.lcs.mit.edu id aa13519;
          30 May 89 20:11 EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 30 May 89 17:09:01 PDT
Received: by fog.cs.uoregon.edu; Tue, 30 May 89 17:08:52 PDT
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8905310008.AA09136@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: another change for R4RS; peek-char

To my great surprise, no one has objected since Jonathan Rees
urged the following change, so I have added the following to my
list of changes planned for the R4RS:

Sections 3.2 (True and false), 4.1.5 (Conditionals),
and 6.1 (Booleans).  It will be explicitly unspecified whether
the empty list counts as true or as false in a conditional
expression.

----------------------------------------------------------------

Here is my summary of discussion so far on two of the changes
expected for the R4RS.

Several people have argued against peek-char, but I do not see
any merit whatsoever in their arguments and I intend to ignore
them.  Those of you who have argued against peek-char may want
to try again, but I am inclined to think that you have not read
the following note in the R3.95RS:

     Note: The value returned by a call to peek-char is the same as
     the value that would have been returned by a call to read-char
     with the same port.  The only difference is that the very next
     call to read-char or peek-char on that port will return the
     value returned by the preceding call to peek-char.  In
     particular, a call to peek-char on an interactive port will
     hang waiting for input whenever a call to read-char would have
     hung.

In light of this note, I do not see why peek-char presents any
difficulties that are not already presented by read-char.  In
particular, I do not see any connection whatsoever between
peek-char and char-ready?, so arguments based upon an alleged
connection between the two will be rejected out of hand unless
they explain the connection.

One person has objected, strongly, to making list-ref and list-tail
essential.  Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?

Peace, Will

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 20:13:45 EDT
Received: from mist.math.uoregon.edu by mintaka.lcs.mit.edu id aa13510;
          30 May 89 20:10 EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 30 May 89 17:07:36 PDT
Received: by fog.cs.uoregon.edu; Tue, 30 May 89 17:07:27 PDT
Date: Tue, 30 May 89 17:07:27 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8905310007.AA09128@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: macros

Hal Abelson wrote:

    I think that, at minumum, R4RS should have a section entitiled
    something like "Provisional proposal for macros"....

    The macro committee should get its collective head together and write
    such a proposal....

    Will, please give the macro committee a deadline for how long you will
    wait for this report....

Ok.  I hereby decree that you folks on the macro committee (you know
who you are!) have until Monday, 19 June, to deliver said report to me
by electronic mail.  I'm leaving for the east coast on the following day,
so this is a firm deadline.

In the event that the macro committee cannot agree on something, Hal
said that the macro committee should

    ...write TWO proposals.  One would be along the lines of
    extend-syntax; the other based upon semantic closures.  The full
    proposal should descibe both of these, together with a brief
    introduction that explains what the issues are, gives reasons why we
    are not yet ready to commit to either proposal (hopefully there are
    reasons, other than political ones), and sets forth some problems that
    we hope to solve in future R*RS documents.  I nominate Jonathan Rees
    to write this overview.

I second the nomination.  Jonathan, I further request that if the macro
committee is unable even to agree on the two-proposal option, then you
should send me a brief note explaining why the committee is unable to
agree.

Peace, Will

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 17:20:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11382;
          30 May 89 17:17 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA13112; Tue, 30 May 89 17:17:38 EDT
Return-Path: <shap@sid.STANFORD.EDU>
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 30 May 89 17:15:11 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA03756; Tue, 30 May 89 14:14:36 PDT
Message-Id: <8905302114.AA03756@mojave.Stanford.EDU>
Received: by sid; Tue, 30 May 89 14:18:37 pdt
Date: Tue, 30 May 89 14:18:37 pdt
From: shap@sid.stanford.edu
To: jinx@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 30 May 89 09:57:39 -0400 <8905301357.AA14423@chamartin.AI.MIT.EDU>
Subject: Requested changes to R4RS

Jinx's correction is right.  Sorry about that.  It should have been:

	(define cadr
	  (let ((car car)
		(cdr cdr))
	    (lambda (x)
	      (car (cdr x)))))

The question remains, however: does R4RS stipulate oneway or the other
whether standard functions can depend on one another?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 May 89 10:00:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25792;
          30 May 89 9:57 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA07340; Tue, 30 May 89 09:57:43 EDT
Return-Path: <jinx@chamartin.AI.MIT.EDU>
Received: from chamartin.AI.MIT.EDU (chamartin.ai.mit.edu) by ZURICH.AI.MIT.EDU; Tue, 30 May 89 09:55:21 edt
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA14423@chamartin.AI.MIT.EDU>; Tue, 30 May 89 09:57:39 -0400
Date: Tue, 30 May 89 09:57:39 -0400
From: "Guillermo J. Rozas" <jinx@chamartin.ai.mit.edu>
Message-Id: <8905301357.AA14423@chamartin.AI.MIT.EDU>
To: shap@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Mon, 29 May 89 13:28:54 -0700 <8905292028.AA01004@polya.Stanford.EDU>
Subject: Requested changes to R4RS
Reply-To: jinx@zurich.ai.mit.edu


    Note, however, that this would preclude an implementation from
    implementing CADR in Scheme in the obvious way:

	    (define (CADR lis) (car (cdr lis)))

    It instead would have to be:

	    (define (CADR lis)
	      (let ((car `,car)
		    (cdr `,cdr))
		(car (cdr lis))))

Why would this help?  Unless I'm very confused, the above is
completely equivalent to

	    (define (CADR lis)
	      (let ((car car)
		    (cdr cdr))
		(car (cdr lis))))

which does not solve the problem.

Maybe you meant

	    (define CADR
	      (let ((car car)
		    (cdr cdr))
		(lambda (lis)
		  (car (cdr lis)))))

Which depends on "loading" order.

To be safe, the implementation would have to define CADR, et al. in an
implementation dependent manner which does not depend on standard
bindings.  A way to achieve this is to have (at least) two different
environments (or top-levels or whatevers).  One of them is the
"system" environment, whose bindings can be depended on.  The other is
the "user" environment, with initial copies of some bindings from the
system environment.  In this way redefining/setting CAR in the "user"
environment will affect user procedures, but not CADR which was closed
in the "system" environment, although initially accesible from the
"user" environment.

In other words, implementations could create their "user" environments
doing something like

;; In the "system" environment

(define car ...)			; The barber of Seville
(define cdr ...)			; The barber of Cordoba
(define cadr				; Shaven by at least two others
  (lambda (p)
    (car (cdr p))))

(define user-initial-environment
  (make-new-environment
   the-empty-environment		; parent
   (CAR car)				; bind CAR in user to the current value of car in system
   (CDR cdr)				; etc.
   (CADR cadr)
   ...))

The read-eval-print loop would then use user-initial-environment
rather than the system environment.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 May 89 16:38:44 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17652;
          29 May 89 16:34 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA01105; Mon, 29 May 89 16:29:17 EDT
Return-Path: <shap@polya.Stanford.EDU>
Received: from polya.Stanford.EDU (polya.stanford.edu) by ZURICH.AI.MIT.EDU; Mon, 29 May 89 16:26:48 edt
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA01004; Mon, 29 May 89 13:28:54 -0700
Date: Mon, 29 May 89 13:28:54 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Message-Id: <8905292028.AA01004@polya.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Requested changes to R4RS

Since we seem to have boiled this down to a concrete issue, I have
re-included rrrs-authors.

   jar@zurich.ai.mit.edu writes:

   As for your question about LOAD, there is *no* procedure in the report
   whose meaning is defined in terms of the binding of any variable in
   the initial environment.  Thus the CADR procedure is not sensitive to
   the bindings of the variables CAR or CDR, and the LOAD procedure is
   not sensitive to the bindings of OPEN-INPUT-FILE or READ.

I don't recall any wording in the standard that says one way or the
other whether things like CADR depend on things like CAR.  Maybe I
just missed it.  If it isn't there, I feel that it should be made
explicit.  As a programmer, I should be entitled to know whether
rebinding READ has an impact on LOAD, etc.

I believe that the right solution is for all of these things to be
independent.  Rebinding one standard function should have no impact on
the behavior of any other.  I would be interested in other opinions.

Note, however, that this would preclude an implementation from
implementing CADR in Scheme in the obvious way:

	(define (CADR lis) (car (cdr lis)))

It instead would have to be:

	(define (CADR lis)
	  (let ((car `,car)
		(cdr `,cdr))
	    (car (cdr lis))))

Making things independent means that I can change things portably.
Users who wish to have things interact are free to re-implement CADR
in terms of CAR and CDR, and similarly for other standard functions.

Jon

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 May 89 15:52:16 EDT
Received: from NSFNET-RELAY.AC.UK by mintaka.lcs.mit.edu id aa17246;
          29 May 89 15:48 EDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa09830; 29 May 89 20:33 BST
Date: Mon, 29 May 89 20:38:56 BST
Message-Id: <10978.8905291938@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: macros
To: rrrs-authors%mc.lcs.mit.edu@nsfnet-relay.ac.uk

I would rather wait longer for the R4RS than to have it sooner but
without macros.

However, I do not think it's a good idea to have two macro proposals.
If I remember correctly from the Snowbird meeting, we were going to
lock some people in a room, and not let them have lunch, until they
came up with a single proposal.

But, according to Will Clinger's message, the problem isn't lack
of agreement:

  Chris Hanson deserves great credit for developing a macro facility
  along the lines envisioned at Snowbird, but the well-specified part
  of it does not seem to be sufficiently powerful.  I gather that the
  system itself is adequately powerful, provided we accept that "the
  implementation is the specification", but we certainly don't want to
  accept that.

-- Jeff

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 May 89 18:53:24 EDT
Received: from Polya.Stanford.EDU by mintaka.lcs.mit.edu id aa09331;
          28 May 89 18:48 EDT
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA04920; Sun, 28 May 89 15:48:26 -0700
Date: Sun, 28 May 89 15:48:26 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Message-Id: <8905282248.AA04920@polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Requested changes to R4RS

About the SYMBOL-VALUE mail.  I was wrong. Thinking about it, however,
has led me to the following question:  Does the specification require
that LOAD use READ? Should it?  Similarly, should READ be required to
be based on READ-CHAR and PEEK-CHAR?

Consider the problem of having a meta-language to describe concisely
something that has a routine expansion into Scheme, but the expansion
is much larger than the concise specification.  If the LOAD routine is
required to use READ, I could contemplate something like:

	(define (myload file)
	   (let ((standard-read read))
	     (set! read myread)
	     (load file)
	     (set! read standard-read)))

where myread does the translation before the interpreter gets a hold
of things.  We can argue about whether or not this is a good idea, but
I think that the standard should make it clear whether this usage can
be relied on or not.

Similarly READ/(READ-CHAR,PEEK-CHAR).  Consider the problem of
internationalizatoin.  It would be nice if I could re-implement
READ-CHAR on top of READ-BYTE to do, for example, Kanji characters.

More generally, there are several standard functions which are
logically implemented on top of more-primitive standard functions, but
the standard does not require any necessary relationship between them.
Should it?  I could argue this either way, and in a few cases, notably
READ and LOAD, I think it is highly desirable.

I would be interested in hearing other opinions.

Jon

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 May 89 16:01:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08072;
          28 May 89 15:57 EDT
Received: from kleph ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA03791; Sun, 28 May 89 15:57:21 EDT
Received: by kleph.AI.MIT.EDU; Sun, 28 May 89 16:01:57 edt
Date: Sun, 28 May 89 16:01:57 edt
From: Chris Hanson <cph@kleph.ai.mit.edu>
Message-Id: <8905282001.AA02147@kleph>
To: shap@polya.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Fri, 26 May 89 15:02:59 -0700 <8905262202.AA06234@polya.Stanford.EDU>
Subject: Requested changes to R4RS
Reply-To: cph@zurich.ai.mit.edu

   Date: Fri, 26 May 89 15:02:59 -0700
   From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>

      Date: Fri, 26 May 89 14:01:43 edt
      From: Jonathan Rees <jar@zohar.ai.mit.edu>

      We need some suitable primitive to permit the construction of portable
      readers.

   If I buy that argument, and I do, then we also need to have
   SYMBOL-VALUE, which opens the EVAL issue.

Care to tell me why a reader needs SYMBOL-VALUE?  I've written several
and never used it.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 18:06:44 EDT
Received: from Polya.Stanford.EDU by mintaka.lcs.mit.edu id aa08151;
          26 May 89 18:03 EDT
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA06234; Fri, 26 May 89 15:02:59 -0700
Date: Fri, 26 May 89 15:02:59 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Message-Id: <8905262202.AA06234@polya.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 26 May 89 15:21 EDT <19890526192116.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Requested changes to R4RS

   Date: Fri, 26 May 89 14:01:43 edt
   From: Jonathan Rees <jar@zohar.ai.mit.edu>


   We need some suitable primitive to permit the construction of portable
   readers.

If I buy that argument, and I do, then we also need to have
SYMBOL-VALUE, which opens the EVAL issue.  As much as I would like to
be able to write READ in Scheme, introducing EVAL is more than I am
willing to pay.

Or did you mean that we need to be able to write portable generic
readers, rather than readers for Scheme?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 18:00:50 EDT
Received: from Polya.Stanford.EDU by mintaka.lcs.mit.edu id aa08063;
          26 May 89 17:57 EDT
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA05884; Fri, 26 May 89 14:56:54 -0700
Date: Fri, 26 May 89 14:56:54 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Message-Id: <8905262156.AA05884@polya.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Fri, 26 May 89 13:40:31 -0400 <8905261740.AA03287@murren.ai.mit.edu>
Subject: macros

I agree with Hal.  In the absence of the macro package specification,
I don't see that R4RS is substantially different from R3RS, though a
lot of clarification has happened.

Jon

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 15:23:56 EDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa13555;
          26 May 89 15:21 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 601762; 26 May 89 15:21:58 EDT
Date: Fri, 26 May 89 15:21 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Requested changes to R4RS
To: jar@zurich.ai.mit.edu
cc: shap@polya.stanford.edu, cph@zurich.ai.mit.edu, 
    rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8905261801.AA04553@zohar>
Message-ID: <19890526192116.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 26 May 89 14:01:43 edt
    From: Jonathan Rees <jar@zohar.ai.mit.edu>

    [Cc: Scheme-Standard deleted]

       Date: Thu, 25 May 89 02:19:56 -0700
       From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>

       I think the peek-char debate centered around what peek-char's behavior
       was in the face of rubout handlers, which evolved from the discussions
       about char-ready?.  The problem is that if we can't define the
       semantics for char-ready?, a good argument can be made that for the
       same reasons we can't define the semantics of peek-char.  If it was
       there to be peeked at, and we can define what that means, then we can
       surely define what char-ready? means.

    We need some suitable primitive to permit the construction of portable
    readers.  Right now there is now way a user can write READ or anything
    similar because there is no way to find out when you've encountered
    the end of a symbol or number without gobbling the character that
    delimits then symbol or number.  I don't care what the primitive is.
    It doesn't have to be PEEK-CHAR, but we've got to have it.  Don't
    just argue against PEEK-CHAR; explain how we can solve the READ problem.

    I think CHAR-READY? is a much less interesting and important question.
    If it is made possible by progress on the READ problem, fine, but
    that's a secondary issue.

    What does X3J13 Common Lisp say about the interaction of PEEK-CHAR and
    input editing?

CLtL has wishy-washy enough wording that it doesn't bother me the way the
Scheme report's wording does.

The description of LISTEN (p380) gives a definition that talks in terms of
`chars available' and in the conditional about what READ-CHAR would do. The
description mostly addresses intent and doesn't make many concrete statements.

The description of PEEK-CHAR (p379) refers to the `next input' rather than
`next call to READ-CHAR' which allows a possible interpretation of CLEAR-INPUT
as an input operation, and so also leaves the wording consistent.

Two X3J13 issues address the behavior of PEEK-CHAR: PEEK-CHAR-READ-CHAR-ECHO
and UNREAD-CHAR-AFTER-PEEK-CHAR. Neither is directly relevant to the issue
at hand, but they are relevant to other things which perhaps the Scheme report
should be considering. 

Summaries:

 PEEK-CHAR-READ-CHAR-ECHO - Discussion of the echo relationship between
   PEEK-CHAR and READ-CHAR. Note that this started out being about both
   `echo streams' and `interactive streams' but X3J13 felt it was out of
   its jurisdiction to address `interactive streams,' so just went ahead
   and left that situation as (in my opinion) a mess. The final passed
   version addresses only echo streams.

 UNREAD-CHAR-AFTER-PEEK-CHAR - Addresses the need to prohibit an UNREAD-CHAR
   after PEEK-CHAR (with no intervening READ-CHAR) [on the same stream].

Disclaimer: 

 Both proposals have been approved by X3J13; however, as with any decisions
 made by X3J13, they might be amended again by subsequent vote.  Further,
 they are not binding on CLtL -- the job of X3J13 is to write a3 ew standard,
 not to rewrite history by amending an existing one. As such, none of the
 decisions mentioned below are necessarily forced on any existing implementation.

Full write-ups follow...

==============================================================================
Issue:        PEEK-CHAR-READ-CHAR-ECHO
References:   READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
	      MAKE-ECHO-STREAM (p330), Streams (p327-328),
	      READ-PRESERVING-WHITESPACE (p376), 
	      READ-DELIMITED-LIST (p377)
Category:     CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
              23-Jun-88, Version 2 by Pitman (remove interactive stuff)
               8-Oct-88, Version 3 by Pitman & Masinter
Status:       Approved by X3J13 on vote of 11-5: proposal FIRST-READ-CHAR
	      
Problem Description:

  The interaction between PEEK-CHAR, READ-CHAR and streams made by
  MAKE-ECHO-STREAM is not made adequately clear about how many times
  a particular character may be echoed and at what time such echo
  is permissible.

  For example, given:
   (WITH-INPUT-FROM-STRING (STRING-STREAM "A")
     (LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
					       *STANDARD-OUTPUT*)))
       (LET ((CHAR NIL))
	 (PEEK-CHAR)             (PRIN1 '---)
	 (PEEK-CHAR)             (PRIN1 '---)
	 (SETQ CHAR (READ-CHAR)) (PRIN1 '---)
	 (UNREAD-CHAR CHAR)      (PRIN1 '---)
	 (READ-CHAR))))
  what is seen on the terminal? There are at least these possibilities:

  [1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
      a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
      re-fetching the char by READ-CHAR doesn't echo.
      A------------

  [2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
      Characters are not unechoed by UNREAD-CHAR.
      A---A---A---A---

  [3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
      No `unecho' action is done by UNREAD-CHAR.
      ------A------A

  [4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR.meEAD-CHAR echos
      but UNREAD-CHAR does not `unecho'.
      A---A---A------A

  [5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
      but UNREAD-CHAR unechos (a magic Erase character must be 
      presupposed for display terminals, a file stream that can randomly
      access during output and/or back up must be presupposed for files,
      paper terminals just lose):
      A<Erase>---A<Erase>---A---<Erase>---A

  [6] PEEK-CHAR is implemented by peeking and does not echo. The first
      time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
      echo, re-fetching the char by READ-CHAR doesn't echo:
      ------A------

  This list is not believed to be exhaustive. It is only to illustrate
  of the variety of possible ways in which the current specification can 
  be implemented without technically being in conflict with the written 
  word of CLtL. Obviously not all of these interpretations are considered 
  useful by all people, but usefulness has not been determined to be 
  criterial in satisfying the specification.

  The description of streams (p327-328) is also [probably deliberately]
  fuzzy on this issue as it relates to operating systems on which echoing 
  is done by the operating system. That is, some systems are line-at-a-time
  and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
  have long since been resolved by a system call that reads and echos input 
  a line at a time. Other systems are character-at-a-time and these issues 
  hit home in a different way. It will probably be necessary to continue
  leaving things slightly unspecified in order to accomodate the native 
  style of the variety of operating systems now trying to support Common 
  Lisp, but we should be more up front about the game we are playing. (For
  example, code which must port between character-at-a-time and 
  line-at-a-time systems must be more careful about whether it does 
  newline-preceded or newline-terminated output than many CL programmers 
  might realize given the current wording.) Additionally, though, we should
  be on the lookout for less ambitious goals involving only partial
  compatibility to improve the situation wherever we can find a way to.

  Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
  are implicitly affected by any decisions made on this issue since their
  descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.

Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):

  Ammend the description of READ-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), the character
  will be echoed on the stream the first time those characters are seen.
  (Characters which are not echoed by READ-CHAR are those which were
  put there by UNREAD-CHAR and hence are assumed to have been echoed
  already by a previous call to READ-CHAR.)

  Ammend the description of UNREAD-CHAR to say that when the stream
  is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
  will be made to undo any echoing of the character which might already
  have been done on the stream. However, characters placed on the
  stream by UNREAD-CHAR will be marked in such as way as to inhibit
  later re-echo by READ-CHAR.

  Ammend the description of PEEK-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), characters
  which are only peeked at are not echoed. Note however that in the
  case that the PEEK-TYPE argument is not NIL, the characters which
  are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
  echoed unless they have been marked otherwise by READ-CHAR.

  Ammend the description of abstract input functions 
  READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
  that they are implicitly affected by these new echoing rules of 
  READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.

  Note: This is consistent with behavior [6] in the problem description.

  Clarify that the echo behavior of interactive streams such as
  *TERMINAL-IO* continues to be implementation dependent.

Rationale:

  Although this is not known to be in use in any particular system,
  nothing prevents its use. It proposes a more rational interpretation
  of the echoing behavior of UNREAD-CHAR which might make it possible
  for programmers concerned about echo behavior not to have to shy
  away from UNREAD-CHAR. (It would probably also improve the behavior
  of READ-PRESERVING-WHITESPACE with regard to echoing, since its
  description mentions using UNREAD-CHAR.)

  Correct echoing behavior is important to programs which do batch
  processing, parsing, etc. Allowing multiple or premature echoing
  is clearly unsatisfactory.

Current Practice:

  A wide variety of behaviors are in use.

Cost to Implementors:

  Unknown.

  The code to implement the proposed change itself is probably fairly
  localized.

  In some operating systems, there may be echoing constraints which
  are overlooked here. 

  In some cases, there may be second order effects in the system 
  itself which would also require a somewhat less predictable amount 
  of work to fix. 

Cost to Users:

  Any change is effectively upward compatible since the previous
  behavior is so ill-specified.

  Most users probably naively expect (perhaps even without realizing
  it explicitly) that echoing will take care of itself. That is, they
  probably expect that echoing will occur at the time of the
  READ-CHAR and probably do not give a lot of thought to the effect
  of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most 
  of their naive intuitions.

Cost of Non-Adoption:

  The streams returned by MAKE-ECHO-STREAM would continue to be
  significantly hard to use portably.

Benefits:

  A number of applications involving of parsers, batch script
  interpreters, and such would be possible to implement
  straightforwardly and portably.

Aesthetics:

  ?

Discussion:

  Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
  he feels it is more practically coherent. However, he says he has
  only mental exercises and no actual personal experience upon which
  to base that belief.

  Version 1 of this proposal treated interactive streams on par
  with echo streams, but while people agreed that this issue is
  a severe portability problem, some considered that the treatment
  of interactive streams got involved in operating system issues
  that were beyond the scope of the standard, so that part of the
  text was removed.
 
==============================================================================
Issue:         UNREAD-CHAR-AFTER-PEEK-CHAR
References:    pp 379, 380 of CLtL
Category:      CLARIFICATION
Edit history:  Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
               Version 2 by Masinter  2-Dec-88
Status:        Approved by X3J13: proposal DONT-ALLOW

Problem description:

PEEK-CHAR and UNREAD-CHAR are very similar mechanisms.  The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession."  But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.

Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): 

   Rewrite the specification so that it is clear that doing either a
   PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
   on any character preceding that which is seen by the PEEK-CHAR (including
   those passed over by PEEK-CHAR when `seeking' with a non-NIL first
   argument) is not specified.

   In particular, the results of calling  UNREAD-CHAR after PEEK-CHAR
   is unspecified.

Example:

   (defun test (&optional (stream *standard-input*))
     (let* ((char1a (read-char stream))	
	    (char2a (peek-char nil stream))
	    (char1b (progn (unread-char char1a stream)
			   (read-char stream)))
	    (char2b (read-char stream)))
       (list char1a char2a char1b char2b)))


This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.

Rationale:

PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.

Current practice:

In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.

In Symbolics Genera, for the Example above:

     (test)ab
     => (#\a #\b #\a #\b)

     (with-input-from-string (s "abc") (test s))
     => (#\a #\b #\a #\b)

     (progn (with-open-file (s "foo.output" :direction :output)
	      (write-string "abc" s))
            (with-open-file (s "foo.output" :direction :input) 
	      (test s)))
     Signals an error about unreading #\a when #\b was already unread.


Cost to Implementors:

Presumably none.  Implementations which allow this are still correct.

Cost to Users:

Small.  I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.

Cost of non-adoption:

Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.

Benefits:

Allows simple yet adequately powerful implementation of sequential streams.

Esthetics:

Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.

Discussion:

<none>


Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 14:36:03 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa03064;
          26 May 89 14:31 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA18098; Fri, 26 May 89 11:30:22 PDT
Date: Fri, 26 May 89 11:30:22 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8905261830.AA18098@sesame.Stanford.EDU>
To: jar@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan Rees's message of Fri, 26 May 89 13:55:27 edt <8905261755.AA04537@zohar>
Subject: truth of ()

   Date: Fri, 26 May 89 13:55:27 edt
   From: Jonathan Rees <jar@zohar.ai.mit.edu>
   Reply-To: jar@zurich.ai.mit.edu


   There was no objection to the proposal that the truth behavior of the
   empty list be unspecified the last two times that the issue came up on
   this list, so I request that you make this change for R4RS.

   [Review of this issue:

   1. R3RS specifies that the empty list must be treated as false by
   conditionals.

   2. The question of ()'s truth was on the agenda for the Snowbird
   meeting but we didn't get around to discussing it.

   3. Someone requested that we require empty list and false to be
   distinct objects.  This request was rejected at Snowbird on
   compatibility grounds.

   4. Someone requested that the empty list MUST be treated as true.
   This is possible only if empty list and false are necessarily
   distinct, and this is not the case.]


I strongly agree with this proposal.  I just want to remind thos concerned that
someone should make a quick pass through 3.95 to make sure that all functions
are specified to return the correct choice between the empty list and #f.
					Morry Katz
					katz@polya.stanford.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 14:10:16 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa29812;
          26 May 89 13:58 EDT
Received: from zohar ([18.43.0.174]) by life.ai.mit.edu (4.1/AI-4.10) id AA03393; Fri, 26 May 89 13:58:08 EDT
Received: by ZOHAR.AI.MIT.EDU; Fri, 26 May 89 14:01:43 edt
Date: Fri, 26 May 89 14:01:43 edt
From: Jonathan Rees <jar@zohar.ai.mit.edu>
Message-Id: <8905261801.AA04553@zohar>
To: shap@polya.stanford.edu
Cc: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Thu, 25 May 89 02:19:56 -0700 <8905250919.AA29734@polya.Stanford.EDU>
Subject: Requested changes to R4RS
Reply-To: jar@zurich.ai.mit.edu

[Cc: Scheme-Standard deleted]

   Date: Thu, 25 May 89 02:19:56 -0700
   From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>

   I think the peek-char debate centered around what peek-char's behavior
   was in the face of rubout handlers, which evolved from the discussions
   about char-ready?.  The problem is that if we can't define the
   semantics for char-ready?, a good argument can be made that for the
   same reasons we can't define the semantics of peek-char.  If it was
   there to be peeked at, and we can define what that means, then we can
   surely define what char-ready? means.

We need some suitable primitive to permit the construction of portable
readers.  Right now there is now way a user can write READ or anything
similar because there is no way to find out when you've encountered
the end of a symbol or number without gobbling the character that
delimits then symbol or number.  I don't care what the primitive is.
It doesn't have to be PEEK-CHAR, but we've got to have it.  Don't
just argue against PEEK-CHAR; explain how we can solve the READ problem.

I think CHAR-READY? is a much less interesting and important question.
If it is made possible by progress on the READ problem, fine, but
that's a secondary issue.

What does X3J13 Common Lisp say about the interaction of PEEK-CHAR and
input editing?

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 13:58:11 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25767;
          26 May 89 13:54 EDT
Received: from zohar ([18.43.0.174]) by life.ai.mit.edu (4.1/AI-4.10) id AA03270; Fri, 26 May 89 13:54:24 EDT
Received: by ZOHAR.AI.MIT.EDU; Fri, 26 May 89 13:55:27 edt
Date: Fri, 26 May 89 13:55:27 edt
From: Jonathan Rees <jar@zohar.ai.mit.edu>
Message-Id: <8905261755.AA04537@zohar>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Thu, 25 May 89 18:06:49 PDT <8905260106.AA18779@fog.cs.uoregon.edu>
Subject: truth of ()
Reply-To: jar@zurich.ai.mit.edu


There was no objection to the proposal that the truth behavior of the
empty list be unspecified the last two times that the issue came up on
this list, so I request that you make this change for R4RS.

[Review of this issue:

1. R3RS specifies that the empty list must be treated as false by
conditionals.

2. The question of ()'s truth was on the agenda for the Snowbird
meeting but we didn't get around to discussing it.

3. Someone requested that we require empty list and false to be
distinct objects.  This request was rejected at Snowbird on
compatibility grounds.

4. Someone requested that the empty list MUST be treated as true.
This is possible only if empty list and false are necessarily
distinct, and this is not the case.]

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 13:51:45 EDT
Received: from MURREN.AI.MIT.EDU by mintaka.lcs.mit.edu id aa10767;
          26 May 89 13:45 EDT
Received: by murren.ai.mit.edu (5.61/1.5)
	id AA03287; Fri, 26 May 89 13:40:31 -0400
Date: Fri, 26 May 89 13:40:31 -0400
From: Hal Abelson <hal@murren.ai.mit.edu>
Message-Id: <8905261740.AA03287@murren.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject:  macros
Reply-To: hal@zurich.ai.mit.edu


I am very unhappy that Will's current that R4RS it will not say
anything about macros.  One of the major agreements at the Snowbird
meeting was the agreements to go ahead with macros.  The momentum of
that decision has been lost, and we need to regain it.

Now that there is a (conservative) Scheme standard beign developed by
the IEEE group, I think we can afford to be less conservative in the
R4RS document.  So I don't feel bad about including something that we
may want to change in a later R*RS.

I think that, at minumum, R4RS should have a section entitiled
something like "Provisional proposal for macros".  This gives us the
option to change the details later, but it serves as a committment
that Scheme DOES have macros, and presents our best current ideas on
the subject.

The macro committee should get its collective head together and write
such a proposal.  Here are two possible forms the proposal might take:

(1) You guys can agree on something.

(2) You can write TWO proposals.  One would be along the lines of
extend-syntax; the other based upon semantic closures.  The full
proposal should descibe both of these, together with a brief
introduction that explains what the issues are, gives reasons why we
are not yet ready to commit to either proposal (hopefully there are
reasons, other than political ones), and sets forth some problems that
we hope to solve in future R*RS documents.  I nominate Jonathan Rees
to write this overview.


The main thing I want to avoid is for R4RS to appear with no macro
proposal at all.

Will, please give the macro committee a deadline for how long you will
wait for this report.  I don't see why it should take more than a week
or two to come up with the two-proposal option, at least.

-- Hal



Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 13:13:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19968;
          26 May 89 13:04 EDT
Received: from kleph ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA01871; Fri, 26 May 89 13:03:29 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by kleph.AI.MIT.EDU; Wed, 24 May 89 15:24:28 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA08243; Wed, 24 May 89 11:12:42 PDT
Date: Wed, 24 May 89 11:12:42 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8905241812.AA08243@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@kleph.ai.mit.edu, scheme-standard@kleph.ai.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 23 May 89 16:25:28 edt <8905232025.AA14941@kleph>
Subject: Requested changes to R4RS

   Date: Tue, 23 May 89 16:25:28 edt
   From: Chris Hanson <cph@kleph.ai.mit.edu>
   Reply-To: cph@zurich.ai.mit.edu

   The following is a list of changes to the R4RS, which are being
   requested by the IEEE Working Group on Scheme.  It would be
   appreciated if the changes could be implemented, or appropriate
   comments generated, in time for the July 7 meeting of the Working
   Group.

   I'm not sure how such things can be decided over the net, but given
   that these changes are believed to be non-controversial, perhaps we
   could take an informal vote after suitable discussion.


   * We request that `list-ref' and `list-tail' have their status changed
   from inessential to essential.

I continue to believe that these functions should be scrapped from the
language altogether.  As a result, I would be opposed to them getting an
upgrade in status.
					Morry Katz
					katz@polya.stanford.edu

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 12:39:46 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08010;
          26 May 89 12:33 EDT
Received: from kleph ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00299; Fri, 26 May 89 12:31:40 EDT
Received: from polya.Stanford.EDU (polya.stanford.edu) by kleph.AI.MIT.EDU; Thu, 25 May 89 21:03:26 edt
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA29734; Thu, 25 May 89 02:19:56 -0700
Date: Thu, 25 May 89 02:19:56 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Message-Id: <8905250919.AA29734@polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@kleph.ai.mit.edu, scheme-standard@kleph.ai.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 23 May 89 16:25:28 edt <8905232025.AA14941@kleph>
Subject: Requested changes to R4RS

I'll buy into all of their requests, though I would hate to lose the
order isomorphism on char->integer and integer->char.

I think the peek-char debate centered around what peek-char's behavior
was in the face of rubout handlers, which evolved from the discussions
about char-ready?.  The problem is that if we can't define the
semantics for char-ready?, a good argument can be made that for the
same reasons we can't define the semantics of peek-char.  If it was
there to be peeked at, and we can define what that means, then we can
surely define what char-ready? means.

Counterargument is to go the route of redefining streams to have
one-character pushback, but that strikes me as having potentially
undesirable consequences down the road.

Jon Shapiro

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 May 89 21:16:12 EDT
Received: from mist.math.uoregon.edu by mintaka.lcs.mit.edu id aa18996;
          25 May 89 21:10 EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 25 May 89 18:07:02 PDT
Received: by fog.cs.uoregon.edu; Thu, 25 May 89 18:06:49 PDT
Date: Thu, 25 May 89 18:06:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8905260106.AA18779@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: planned changes to R3.95RS

I have agreed to delay the R4RS until after the P1178 meeting in
early July.  Aside from formatting and the changes listed below,
I expect the R4RS to be identical to the R3.95RS.  Please let me
know if any other changes are called for, or if any of the changes
listed below should not be made.

William Clinger

----------------------------------------------------------------
Here is a list of the changes that I plan to make to the R3.95RS
to obtain the R4RS.  Changes that (in my opinion) do not change the
technical content are identified as an [Editorial change.].

Sections 2.1 (Identifiers), 2.3 (Other notations), and 7.1.1 (Lexical
structure).  Add ... as a new peculiar identifier.

Section 4.2.5 (Delayed evaluation).  [Editorial change.]
Change "complete description" to "more complete description".

Section 6.3 (Pairs and lists).  Make list-ref and list-tail essential.
(We rejected this at Snowbird, but the editors of the IEEE draft
standard have requested that we reconsider.)

Section 6.5.1 (Numerical types).  [Editorial change.]
Change the two occurrences of "while" to "although".

Section 6.5.4 (Syntax of numerical constants).  [Editorial change.]
Replace the three opening sentences of the fourth paragraph by

    In systems with inexact numbers of varying precisions it may be
    useful to specify the precision of a constant.
    For this purpose, numerical constants may be written
    with an exponent marker that indicates the desired precision
    of the inexact representation....

Section 6.5.5 (Numerical operations).  [Editorial change.]
Add the following example to the description of round:
    (round 7/2) ==> 4

Section 6.5.5 (Numerical operations).  Change the equation for
inverse tangent from
     $$\tan^{-1} z = -i \log ( (1 + i z) \sqrt{1/(1 + z^2)} )$$
to the new equation voted by X3J13 (Common Lisp):
     $$\tan^{-1} z = (log (1 + i z) - log (1 - i z)) / (2 i)$$
This changes the branch cuts for atan, affecting programs
that call atan with imaginary arguments.  The change has
no effect on the behavior of atan with real arguments.

Section 6.6 (Characters).  Require that char->integer and
integer->char be one-to-one.  (Note that this does not satisfy
the request by the authors of the IEEE draft standard; see below.)

Section 6.7 (Strings).  The char-upper-case? procedure, which
I accidently deleted from this section, will be restored.

----------------------------------------------------------------
Here is a discussion of some requested changes that I do not plan
to make.  The first few (starred) requests were made by Chris
Hanson, on behalf of the IEEE editors, in a recent message.

  * We believe that `peek-char' is underspecified and request that the
  specification be improved.  [Does anyone remember the arguments?  It's
  possible that the added note in R3.95RS is sufficient -- cph]

I believe the arguments mostly had to do with the behavior of
peek-char on interactive ports, but some of the arguments may have
had to do with problems occasioned by multitasking.  I believe the
note in R3.95RS clarifies the behavior of peek-char on interactive
ports, so that its behavior is as well-defined as that of read-char.
There is a legitimate question concerning the behavior of peek-char
in the presence of multitasking, to which there are two obvious
answers, but I don't believe the question is of enough practical
importance to delay the acceptance of peek-char while we try to
decide between them.

  * We suggest that `integer->char' and `char->integer' should be
  constrained more carefully.  In particular, the order isomorphism
  requirement seems excessively strong; perhaps a one-to-one map
  requirement would be more appropriate.

From the programmer's point of view, the order isomorphism is a
nice property, and I've never heard anyone complain that it would
be difficult or inefficient to implement on some system, so I don't
understand the argument for change.  The main thing wrong with it
is that it appears to be legal for an implementation to make
(char->integer c) be 0 for all characters c, and to make
(integer->char 0) be #\a.  I plan to fix this by requiring that they
be one-to-one, but that makes the requirement stronger, not weaker.
             
  * We request deleting the "alphabetic" restriction on the domains of
  `char-upper-case?' and `char-lower-case?' (extending these domains to
  all characters), defining the procedures to return #F for
  non-alphabetic characters.

This is already done in R3.95RS.

Someone suggested that the specification of delay and force be
tightened up in a certain, very specific way.  I felt this would be
inconsistent with the rest of the deliberately loose specification
of promises.

Several people objected to the discussion of mutable and immutable
objects in section 3.5 (Storage model).  These objections fell into
three groups.  Some people just forgot the difference between "is an
error" and "signals an error".  Others, perhaps confusing semantics
with implementation, objected on the grounds that no Scheme procedures
were provided to test or set what they perceived as a "mutability bit".
The third group objected in principle to read-only constants.  I take
the third group seriously, but I am more convinced by the following
arguments in favor of read-only constants: (1) Scheme constants have
been read-only since the R3RS, and the burden of proof should lie with
those who advocate change; (2) constants are read-only in most
programming languages (exceptions include C and Smalltalk), and
most programmers seem to agree that side-effecting a constant is poor
style even if it is allowed; and (3) read-only constants are important
for some embedded systems, an application area for which Scheme seems
well-suited.

There still seems to be no consensus on another name for letrec.

Chris Hanson deserves great credit for developing a macro facility
along the lines envisioned at Snowbird, but the well-specified part
of it does not seem to be sufficiently powerful.  I gather that the
system itself is adequately powerful, provided we accept that "the
implementation is the specification", but we certainly don't want to
accept that.  I think we are very close to having a well-specified
system that does what we need, but I recommend that the R4RS not
include a macro facility because we're not quite there yet.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 May 89 13:50:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa03686;
          24 May 89 13:46 EDT
Received: from kleph ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA10631; Wed, 24 May 89 13:45:55 EDT
Received: by kleph.AI.MIT.EDU; Tue, 23 May 89 16:25:28 edt
Date: Tue, 23 May 89 16:25:28 edt
From: Chris Hanson <cph@kleph.ai.mit.edu>
Message-Id: <8905232025.AA14941@kleph>
To: rrrs-authors@kleph.ai.mit.edu
Cc: scheme-standard@kleph.ai.mit.edu
Subject: Requested changes to R4RS
Reply-To: cph@zurich.ai.mit.edu

The following is a list of changes to the R4RS, which are being
requested by the IEEE Working Group on Scheme.  It would be
appreciated if the changes could be implemented, or appropriate
comments generated, in time for the July 7 meeting of the Working
Group.

I'm not sure how such things can be decided over the net, but given
that these changes are believed to be non-controversial, perhaps we
could take an informal vote after suitable discussion.


* We request that `list-ref' and `list-tail' have their status changed
from inessential to essential.

* We believe that `peek-char' is underspecified and request that the
specification be improved.  [Does anyone remember the arguments?  It's
possible that the added note in R3.95RS is sufficient -- cph]

* We suggest that `integer->char' and `char->integer' should be
constrained more carefully.  In particular, the order isomorphism
requirement seems excessively strong; perhaps a one-to-one map
requirement would be more appropriate.

* We request deleting the "alphabetic" restriction on the domains of
`char-upper-case?' and `char-lower-case?' (extending these domains to
all characters), defining the procedures to return #F for
non-alphabetic characters.

Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 16:08:36 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa01459;
          20 May 89 15:13 EDT
Received: by iuvax.cs.indiana.edu 
Date: Sat, 20 May 89 14:12:23 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu, 
    scheme@mc.lcs.mit.edu
Subject: next meeting of the IEEE Scheme WG
Message-ID:  <8905201513.aa01459@mintaka.lcs.mit.edu>

The next meeting of the IEEE Scheme Standardization Working Group will be

		9:30am-5pm, Friday, July 7th, at MIT.

The exact location will be announced later.  The numbers section will
be a major agenda item, and William Clinger will attend.  Let me know
if you plan to attend (so local arrangements can know about how many
to expect) and if you have any other suggestions for the agenda.

Christopher Haynes, IEEE Scheme WG Chair
Lindley Hall, Indiana University, Bloomington, IN 47405
chaynes@iuvax.cs.indiana.edu
812/855-6486

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Apr 89 04:47:37 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA12709@chamartin.AI.MIT.EDU>; Sun, 23 Apr 89 03:47:31 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA24252; Sun, 23 Apr 89 01:46:58 -0700
Date: Sun, 23 Apr 89 01:46:58 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904230846.AA24252@polya.Stanford.EDU>
To: rrrs-authors@chamartin.AI.MIT.EDU
Subject: Rebinding of standard functions


Well, having been responsible for kicking this off, let's see if I can
divert the deluge.  I apologize for the furor my ignorance has loosed...

There is merit on both sides of the arguments for and against
redefining standard functions.  On the FOR side, people correctly
point out that it is extremely useful to be able to extend the
existing primitives.  On the AGAINST side, people correctly point out
that this prevents efficient code generation and leads to hard-to-find
errors.

While the efficiency and [human-]correctness arguments have no bearing
on the mathematical soundness of the language, I don't think it
inappropriate to try and address these concerns if it can be done
without jeopardizing that soundness.

Some will undoubtedly point out that such hacks as

	(letrec ((+ `,+)
		 (- `,-))
	  ..body..)

already address the need.  While this is true from a formal
standpoint, it renders debugging difficult and substantially detracts
from the readability of the code.

Perhaps the time has come, in the interest of portability, for an
attempt to be made to resolve this issue.

First, is this appropriate, and if so, what is the mechanism used to
accomplish this sort of thing in the scheme community?

I would volunteer to think about this a while and propose a solution
[AFTER reading through the archives...], but I wonder if in my
ignorance I won't stir up more problems than I resolve.

Any reactions?

Jon Shapiro

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Apr 89 04:44:29 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA12703@chamartin.AI.MIT.EDU>; Sun, 23 Apr 89 03:44:39 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA24196; Sun, 23 Apr 89 01:44:08 -0700
Date: Sun, 23 Apr 89 01:44:08 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904230844.AA24196@polya.Stanford.EDU>
To: rrrs-authors@chamartin.AI.MIT.EDU
Subject: Why the interest

Somone sent me mail asking what has suddenly sparked my interest in
Scheme, and if I was doing an implementation.

The answer is yes, I am doing an implementation, partly to understand
the issues in implementing a language with first-class functions and
continuations, and partly because having looked at it from a number of
angles, I find Scheme a marvelously well-executed and thought-out
language, and would like to base a book I am writing on it.

Most of the "difficulties" I see in the current language, given my
interests, have to do with the ability to express cues to the
implementation for efficient compilation, and I am particularly
interested in thinking about ways to express these things that do not
jeopardize the mathematical soundness of the language.

And there you have it...

Jon

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 19 Apr 89 15:11:15 EDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA29231; Wed, 19 Apr 89 14:16:55 EST
Date: Wed, 19 Apr 89 14:16:55 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8904191916.AA29231@void.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: test message
Reply-To: jar@zurich.ai.mit.edu

Testing the mailing list.  Please ignore.

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 19 Apr 89 11:08:12 EDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA29111; Wed, 19 Apr 89 10:12:58 EST
Date: Wed, 19 Apr 89 10:12:58 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8904191512.AA29111@void.ai.mit.edu>
To: shap@polya.stanford.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 17:53:13 -0700 <8904190053.AA22919@polya.Stanford.EDU>
Subject: Confusion with peek-char and char-ready
Reply-To: jar@zurich.ai.mit.edu


Regarding the question of the interaction between PEEK-CHAR,
CHAR-READY?, and input editing, I think we should first check to see
what the Common Lisp cleanup committee has figured out; I know they
have considered this problem, and there's no sense in us reinventing
the wheel if they've figured out something reasonable.  Could someone
out there who follows cl-cleanup stuff investigate for us?

The main reason I would like to see PEEK-CHAR in Scheme is so that it
becomes possible to write something like READ in a portable way.  READ
has the property, not explicitly stated but I believe assumed, that if
the file contains "foo)" and you do READ followed by READ-CHAR, you
get the symbol FOO and the character #\).  In order to write READ, you
have to have a way to determine whether you have arrived at the end of
a symbol, number, etc. either by hitting a delimiter or by hitting end
of file.  The definition of PEEK-CHAR or any replacement for it should
be whatever it has to be to support this application.

Perhaps we don't need the full generality of PEEK-CHAR to get this
functionality, though.  E.g. if the language had something like C
Scheme's character sets, we could have READ-CHAR-IF-IN-CSET, which
would read a character if it was among a given set and return #f
otherwise.  I'm not proposing this, just mentioning it to point out
that there may be alternatives that don't get us into as much trouble.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 19 Apr 89 09:58:52 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA09483@chamartin.AI.MIT.EDU>; Wed, 19 Apr 89 08:58:27 -0500
Date: Wed, 19 Apr 89 08:58:27 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904191358.AA09483@chamartin.AI.MIT.EDU>
To: shap@polya.Stanford.EDU
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 17:42:48 -0700 <8904190042.AA22474@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu

    On the other hand, I now agree that read/write shouldn't return #f or
    #t.  The problem is, I really don't want to have to be killed (an
    error is signalled...) when a read/write fails.  I believe that the
    best solution would be to add a third optinal argument to everything
    that takes a port, the argument being of the form

Hopefully a condition/error handling subsystem will be added to a
future version of the standard.  In the meantime condition handling is
implementation dependent.

As far as WRITE is concerned, I think it should handle all kinds of
objects, and signal no errors of this kind.



Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 19 Apr 89 09:55:44 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA09480@chamartin.AI.MIT.EDU>; Wed, 19 Apr 89 08:54:53 -0500
Date: Wed, 19 Apr 89 08:54:53 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904191354.AA09480@chamartin.AI.MIT.EDU>
To: shap@polya.Stanford.EDU
Cc: rrrs-authors@chamartin.AI.MIT.EDU, scheme-standard@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 16:58:34 -0700 <8904182358.AA19933@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu


	    A correct analogous program would be

	    (define mystring (string-copy "abc"))
	    (string-set! mystring 0 #\f)

    I really don't care for this.  It makes strings substantively
    different from vectors, when conceptually they ought not be.  Further,
    why is it that strings are reasonable things to put into immutable
    space and lists, lambdas, etc. are not?

There is no difference between strings, vectors, and lists at this
level.  Your example used strings, so I just rewrote it to be correct.
Vector and list literals can be immutable as well and the same would
apply to them.  As far as lambdas, they are not objects in the
language.  Procedures are immutable in the standard since no
operations that destructure/mutate them are provided.  Lists
representing lambda expressions and which evaluate to procedures are
just lists, so anything applying to lists applies to them as well.

I'm not defending immutable structures, I'm just interpreting the
report and the understanding of the authors at this point.  Besides
the obvious implementation desire to put such literals in "immutable
space", there are other reasons, the main of which is that the static
meaning of programs becomes harder to determine if literals are
mutable.

    After seeing Jinx's response, [I still am not sure he was serious...]
    it seems all the more important that section 3.5 make it explicitly
    clear that an object is only a candidate for immutable storage if the
    implementation can prove that it cannot be mutated by the program.

I was dead serious.  

What you suggest would prevent most literals from becoming immutable
since they are externally visible or returned to the "outside world"
inside of lists or other structures which can be destructured outside.

Note that personally I don't really care what the report says about
mutating literals.  I consider doing it bad style, but I don't like to
legislate style.  Maybe one of the proponents of immutable literals
can better answer your objections.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:53:20 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA09126@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:53:44 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA22919; Tue, 18 Apr 89 17:53:13 -0700
Date: Tue, 18 Apr 89 17:53:13 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190053.AA22919@polya.Stanford.EDU>
To: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Conusion with peek-char and char-ready

The conflict with char-ready? vs rubout handlers arises with peek-char
also, and it is very bad that the current draft requires no guarantee
that what I get from PEEK-CHAR is what I will get from a subsequent
READ-CHAR [I suspect this is a temporary editing discontinuity
introduced by the removal of CHAR-READY?].  This is emphatically *not*
the right thing, as it leads to an ambiguity in usage: one usage is to
use PEEK-CHAR to watch the instantaneous input stream, the other is to
do lookahead.  If the relationship between PEEK-CHAR and READ-CHAR is
not strengthened, this confusion will get embedded in programs in
subtle ways.

The problem arises out of a confusion between readahead and
rubout/kill processing. In the presence of rubout handling,
CHAR-READY? should only return #t if there is input that has been
committed (on a UNIX system, if return has been pressed for the input
line).  In the absence of rubout handling, (i.e. raw mode I/O),
CHAR-READY should return #t if a character has been typed.

This is getting pretty deep into terminal I/O specific stuff, and it
isn't clear to me that we ought to do that.

The problem can be temporarily resolved by restoring CHAR-READY? with
the interpretation above and introducing something like

	(I/O-MODE <port> 'BUFFERED)
	(I/O-MODE <port> 'RAW)

I think it would be better to do this than standardize on an I/O
facility in which there is no way to guarantee non-blocking read.

I am in general greatly concerned that the IEEE standardization is
very premature, and will lead to diverging practices in commercial
implementations that will make the language nearly impossible to
converge later.

Jon

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:43:06 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA09116@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:43:31 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA22474; Tue, 18 Apr 89 17:42:48 -0700
Date: Tue, 18 Apr 89 17:42:48 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190042.AA22474@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard

Now that I have had a chance to think about jinx's response on
read/write, and talked this over with M. Shaff as well.

Regarding the problem of read/write invertability, peace.  Hadn't
thought it through, though I still maintain that there is merit to
standardizing the interfaces to dumpheap and dumpworld.

On the other hand, I now agree that read/write shouldn't return #f or
#t.  The problem is, I really don't want to have to be killed (an
error is signalled...) when a read/write fails.  I believe that the
best solution would be to add a third optinal argument to everything
that takes a port, the argument being of the form

	(lambda args ..body..)

Which is the continuation to be called with some
implementation-specific arguments.  An error should be signalled only
in the absence of such a continuation.

Thus:

	(write <value> [ <port> [ <error-continuation> ]])

Comments?

Jon

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:33:11 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA09106@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:33:33 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA22078; Tue, 18 Apr 89 17:32:17 -0700
Date: Tue, 18 Apr 89 17:32:17 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190032.AA22078@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard

Procedures/immutability

Jinx pointed out (as did Mike Shaff) that my posting is unclear.
After talking this one through with Mike Shaff, he and Ifeel that this
issue deserves some discussion, though the results may not be
applicable to the IEEE standard.

As we see it, there are two things we might want to be able to say
with respect to mutability:

	(define-immutable fred value)

says that the binding of fred to value cannot be changed.  The value
of the storage may change if there exists a mutator to alter it, thus:

	(define-immutable mylist '(a b))
allows
	(set-car! mylist 1)
but not
	(set! mylist fred)

This construct is not theoretically necessary, but neither are a lot
of other things in scheme.  What makes such a construct desirable is
that if I can show that there is no mutator that can act on the
relevant value, it frees me to do partial evaluation.  If the value is
a lambda, this is enough to let me do procedure integration.

We could argue that this construct would be better expressed by

	(declare immutable <name>)     [syntax]

A DECLARE form would be permissable in any context that a define form
is permissable.  Thinking about it, I prefer this syntax, as it works
for let-bindings as well as defines.

Note that a binding being immutable is not something that causes
contamination.  It is okay to say

	(let ((b mylist)) ..body..)

and do whatever I please to B.

The second thing that we want to say something about is immutability
of values.  By this, we might use:

	(define-immutable constant-fred (constant (list '(a b))))

The (constant X) item entitles to put the value in immutable storage,
and makes it an error to do an operation that side-effects the value.
This property is contaminating. Given,

	(let ((b constant-fred)) ..body..)

B is a mutable binding to an immutable value.

Now, I am satisfied that I understand DEFINE-IMMUTABLE, though I
debate about DEFINE-IMMUTABLE vs DECLARE.  It should either be
nonreversable (i.e. once a binding is made immutable I am stuck) or it
should have temporal scope lasting until the binding is made mutable
again using (DECLARE MUTABLE <name>).  Evaluations in the interim are
entitled to have assumed integrability.

I don't like the CONSTANT construct.  First, it really wants to be
syntax, because if it takes any value it can have really ugly
propagational effects.  What you want, it seems to me, is to have
either a separate set of constructors for constant objects or a syntax
that can be wrapped around the constructors.  I don't know which I
like better.  In either case, a (CONSTANT?) would need to be added.

I would like to see some discussion of this on the scheme lists.

Finally, to the original question, which has since been answered.  Are
the standard function bindings mutable.  The answer is apparently
"yes", and thanks to those who answered.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:07:54 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
	id <AA09084@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:08:18 -0500
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA19933; Tue, 18 Apr 89 16:58:34 -0700
Date: Tue, 18 Apr 89 16:58:34 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904182358.AA19933@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: rrrs-authors@chamartin.AI.MIT.EDU, scheme-standard@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard

I was talking about the ieee standard in my comments.

In response to my strings-immutable coment, Jinx suggested:

	A correct analogous program would be

	(define mystring (string-copy "abc"))
	(string-set! mystring 0 #\f)

I really don't care for this.  It makes strings substantively
different from vectors, when conceptually they ought not be.  Further,
why is it that strings are reasonable things to put into immutable
space and lists, lambdas, etc. are not?

No, if what you want is to be able to have things in constant space,
introduce a construct that says so. Don't perturb well understood and
correct behavior.

After seeing Jinx's response, [I still am not sure he was serious...]
it seems all the more important that section 3.5 make it explicitly
clear that an object is only a candidate for immutable storage if the
implementation can prove that it cannot be mutated by the program.

Jon

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 17 Apr 89 18:58:19 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA07765@chamartin.AI.MIT.EDU>; Mon, 17 Apr 89 17:58:25 -0500
Date: Mon, 17 Apr 89 17:58:25 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904172258.AA07765@chamartin.AI.MIT.EDU>
To: shap@polya.stanford.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Jonathan S. Shapiro's message of Sat, 15 Apr 89 20:24:25 -0700 <8904160324.AA17433@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu

    I recently grabbed a copy of the standard dated April 15 from
    zurich.ai.mit.edu.  Since I am new to the scheme community, it would
    be presumptuous to assume that I have understood the subtleties of all
    of the standard, but there are some areas that were unclear to me or
    seemed to permit contradictory interpretations, and I thought I would
    send out comments on these areas.

Which standard?  Do you mean the ieee standard or the informal r4rs
report?  The scheme-standard mailing list deals with the ieee
standard, while rrrs-authors deals with the informal report.  Many
issues are important to both mailing lists, so sending mail to both is
probably the right thing to do since there are some people on one but
not the other.  I think that your comments apply to r4rs, not the ieee
standard, so the message should have been sent to rrrs-authors as well.

    I commend to your consideration adding an implementation note pointing
    out the advantage of introducing of a special value, #undefined, which
    is "returned" when an evaluation results in an unspecified value.

    Rationale: The presence of such a value substantially simplifies
    debugging by permitting the environment to analyze precisely the
    nature of an error (i.e. the implementation doesn't have to worry
    about debugging random pointers).

    In light of lack of experience and agreement about this construct, it
    would be inappropriate to standardize it at this time, but it would be
    appropriate to mention it in an implementation notes aside.

I mostly agree with your recommendation, but your rationale does not
quite hold.  The "problem" with unspecified values is that they can
propagate for an unbounded amount of time before anyone actually tries
to do something with them that will fail.  For example, they can be
stored in a data structure which will not be examined until much
later.  At the point at which the unspecified object causes an error,
there is often no context from the process that created the
unspecified object, so debugging is not really enhanced.

The return values of certain expressions are left unspecified for a
variety of reasons:

- No agreement within the community on what the return value should
be.  See below the case of SET!

- Agreement that no value is especially useful and/or meaningful.  In
this case the implementation does not have to track down some other
value, and can return something more convenient.

Another possibility would be a class (type) of unspecified objects
which would capture some "essential" aspect of the situation in which
they were created/returned.  This could be made much more useful for
debugging, but would probably incur some performance problems.  I
won't suggest requiring/recommending this.

----------------------------------------------------------------------

    I think there is a conflict implied between this paragraph and
    paragraph 3 of this section.  The conflict is exemplified by:

	    (define mystring "abc")
	    (string-set! mystring 0 #\f)

    The third paragraph as written implies that "abc" can be allocated in
    read-only memory, and since string-set! does not "create" a new
    object, paragraph one implies that read-only memory can be
    side-effected.  See my proposed rewording to paragraph 3.

There is another interpretation, which is that the STRING-SET! is in
error for attempting to modify an immutable object.  The last sentence
of the third paragraph of this section in r3.95rs says precisely this.

A correct analogous program would be

(define mystring (string-copy "abc"))
(string-set! mystring 0 #\f)

An altogether different problem is that of determining whether an
object is immutable.  Maybe an IMMUTABLE? predicate should be added to
the language, so that user written procedures can detect this case and
give a meaningful error message rather than causing an error in the
middle of system code.

----------------------------------------------------------------------

    This paragraph could be misread to imply that objects must be
    implemented with "in-use" bits.  While this is a common implementation
    method, it should be thought of as a conceptual approach, not an
    implementation constraint.  The wording also implies that the in-use
    bits must always be kept up-to-date, which clearly is undesirable.

Would you be happy if the word "conceptually" were inserted before
"marked" at the beginning of the paragraph?

    Other:

    It might be helpful to note here somehow that there is useful
    constraint that is not as strong as "immutable".  There is a class of
    objects named by top-level symbols that may be mutated but not resized
    or rendered out-of-use, and it might be worth adding a paragraph to
    point out that these can always be considered to be allocated.  [Point
    being to partition them from the space considered for garbage
    reclamation].

I don't think that is reasonable for the standard.  Implementations
may support objects in static areas, but I don't think that the
language itself should concern itself with such issues.

----------------------------------------------------------------------

    The result of SET! being unspecified is sufficiently unusual that I
    would be curious as to the rationale.  To my knowledge, no semantic
    difficulties are introduced by having SET! return the value, and there
    is enough code out there that makes this assumption that in the
    absence of a compelling reason to remove it SET! should return the
    value.

There is disagreement in the community about what the return value
should be.  MIT Scheme follows the convention that assignment (ie. SET!)
and slot assignment procedures (ie. SET-CAR!, STRING-SET!, etc.)
return the OLD contents, not the new value.  Other implementations
follow the more usual convention of returning the new value.
Code making the assumption that any particular convention holds is
not portable.

----------------------------------------------------------------------

    The standard does not specify the meaning of

	    (define <variable>)

    which is in sufficiently common usage that it should be included.
    <variable> should be bound to an unspecified value.

I agree, but I think there was some discussion about this, and it was
dropped, but I don't remember the reason.

    Also, the semantics of DEFINE is historically problematic.  The
    change in R3RS that eliminated the implicit LETREC in defines forces
    me to generate code that checks to see if the procedure's variable has
    been side effected by someone I call before I do the tail-recursive
    call.

That's not quite true.  This behavior can be achieved by the following
implementations:

- Fetch the operator of the call by indirecting through a cell.
Assignments modify this cell.
- Assignment becomes "smart" about modifying the operators of certain
calls, and "does the right thing".

Furthermore, a programmer who wants to preclude the possibility of
assignment to the variable can do so by using

(define foo
  (letrec ((foo (lambda ...)))
    foo))

or

(define (foo .args.)
  (letrec ((foo (lambda ...)))
    (foo .args.)))

    If this change is made (I am sending this proposal to the scheme group
    too), then the common case rewrite rule is:

	    (define name	  =>  (begin (define name)
	       (lambda ...))	     (set! name
					   (letrec ((name (lambda ...)))
					      name)))

Note that here you are suggesting something even more drastic than
what r2rs had.  In r2rs

(define foo (lambda (x) ...))

and 

(define (foo x) ....)

were NOT equivalent, since the second form had in implicit LETREC in it.

I'm also not sure that I agree with you that the expansion with LETREC
is desirable as a default.  The differences between the two cases
above in r2rs and this question about desirability are the reasons
that the semantics was changed for r3rs.  Although your proposal would
make the meaning of both forms be the same, I suspect you will find a
fair amount of opposition (including myself) to having an implicit
LETREC in

(define foo (lambda (x) ....))

----------------------------------------------------------------------

    It should be specified whether the standard-procedures are considered
    immutable or not.  I could make a good compiler argument for them
    being immutable and a good user argument for them being mutable (can
    add polymorphism through appropriate SET! and LET hacks).  It is my
    opinion that this decision should not be left to the implementation.

I don't know what you mean about procedures being immutable.  Do you
mean mutating the procedure object or changing the value of the
variable which initially holds a standard procedure?  The language as
it currently appears provides no means for destructuring and mutating
procedure objects.  As far as assigning those variables, I think it is
allowed by the language.  My understanding of the paragraph on
immutable data is that only literal constants can be made immutable,
but there are no literal bindings.

----------------------------------------------------------------------

    Write should return #f on failure and #t on success, or it should be
    an error to write a value to an external port that lacks an external
    representation.

There are two different issues here:

- One is whether WRITE should do something useful with all objects.

- The other is WRITE/READ invertibility, that is whether the output of
WRITE should always be valid input to READ and should cause READ to
return/create an object similar (same?) as that given to WRITE
originally.

Although the report does not explicitely state it (maybe it should),
I think that the authors agree that WRITE should accept all objects as
arguments and "print" something descriptive.

I don't think there is agreement that WRITE should be able to "print"
a "complete" representation of a procedure or a continuation, or what
this would mean.  At the core of the matter is the fact that although
the notion of procedural equivalence is mathematically well defined,
it is not decidable, so there would be no way to effectively test a
WRITE/READ pair and ultimately to "know" what to print.  Any other
definition of similarity between procedures would be artificial and
likely to cause confusion and problems.

An altogether different issue is whether we should adopt the C
convention of returning an arbitrary value when an unhandled situation
occurs or whether we should signal an error.  In general I don't
believe in returning arbitrary values as a substitute for errors,
although I think there are some cases (like STRING->NUMBER) were we
can make an exception because of common usage.  I don't think that
WRITE falls in this category.

    The standard shouldn't include DUMP-HEAP, but it shouldn't constrain
    WRITE in a way that prohibits it either.

I think this is already true.  Although I doubt that DUMP-HEAP would
be written in terms of WRITE.

----------------------------------------------------------------------

    1) Implementations should be encouraged somewhere to implement (WRITE
    <continuation>).  A representation should be written that when read
    with READ results in a thunk that is an equivalent function to the
    written continuation.  The representation of continuations should be
    implementation-defined.

I don't know what that means.  What do you mean by an equivalent
function?  Should all environment information be "re-interned" on the
way in so that side effects by the original continuation are visible
by the "new" continuation and viceversa?

    Rationale:  We all acknowledge that this is pragmatically something
    that we want, and there should be a standard interface.  Having write
    return a value lets me assume the capability without causing problems
    for implementations that don't support it.

I'm not sure I want something that I don't understand.  It would have
to be very well and clearly defined for me to accept it.

----------------------------------------------------------------------

    2) I believe that the user-interface section should specify a
    procedure (DUMP-WORLD "filename" <continuation>) that writes a
    representation that can be executed in an implementation-dependent way
    to arrive at the specified continuation.  The <continuation> argument
    should be optional, and if left unspecified should default to the
    continuation that DUMP-WORLD will return to.  DUMP-WORLD should return
    #t if it succeeds or #f if it fails or the implementation doesn't
    supply the functionality.

As I said above, I don't believe in procedures returning arbitrary values rather
than signalling errors.

    Rationale:  The whole community acknowledges that we want this, but
    that it is implementation-dependent.  This proposal permits us to
    specify the interface to it and construct our programs in a way that
    deals gracefully with failure and doesn't impose it on
    implmementations that don't or can't do it.

    Why DUMP-WORLD and not DUMP-HEAP?  Unlike DUMP-HEAP, which is covered
    by WRITE, DUMP-WORLD does something fundamentally
    implementation-specific.

In general, we decided to drop most user interface and development
environment procedures because we could easily envision environments
where they did not make sense.  The current consensus is that most of
those procedures should not be in the language.  Programs that depend
on this kind of functionality can be structured so that the
dependencies are restricted to a few modules which can be easily
rewritten for similar environments.

I think that LOAD and the transcript procedures have been dropped from
the draft ieee document for this reason.

Received: from hx.LCS.MIT.EDU (TCP 2207400305) by MC.LCS.MIT.EDU  5 Apr 89 15:19:27 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Wed, 5 Apr 89 15:15:53 EDT
Date: Wed, 5 Apr 89 15:15:53 EDT
From: ziggy@hx.LCS.MIT.EDU (Michael R. Blair)
Message-Id: <8904051915.AA26396@hx.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: R^3.95 non-idealities (anal)


 I noticed that, like the R^3 Report, that
CATCH and RETURN are in the index. Is this
an oversight? If not, I don't understand why
EXIT and GOTO are not.
				~Ziggy

Sorry to send this to the entire list, but
I just don't have any luck trying to send
directly to Will.

Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU  5 Apr 89 11:42:55 EDT
Received: by kleph.ai.mit.edu (5.59/1.5)
	id AA16637; Wed, 5 Apr 89 10:44:18 EST
Date: Wed, 5 Apr 89 10:44:18 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8904051544.AA16637@kleph.ai.mit.edu>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@kleph.ai.mit.edu
In-Reply-To: William Clinger's message of Tue, 4 Apr 89 16:33:08 PDT <8904050033.AA06109@fog.cs.uoregon.edu>
Subject: ftp'able R3.95RS
Reply-To: cph@zurich.ai.mit.edu

   Date: Tue, 4 Apr 89 16:33:08 PDT
   From: William Clinger <will@fog.cs.uoregon.edu>

   Did you receive my message saying that I had ftp'ed the R3.95RS to zurich/tmp?
   I haven't seen any announcement of it.  Are you in circulation?  Please
   acknowledge this message.

   Peace, Will

The R3.95RS sources are available via anonymous ftp from
"zurich.ai.mit.edu", as one of the following files:

pub/scheme-reports/r3.95rs.tar
pub/scheme-reports/r3.95rs.tar.Z

Sorry for the delay -- I've been on vacation and just returned.

Received: from hx.LCS.MIT.EDU (TCP 2207400305) by MC.LCS.MIT.EDU  4 Apr 89 22:56:08 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 4 Apr 89 22:52:37 EDT
Message-Id: <2816736980-5305984@RTS-8>
Sender: ziggy@RTS-8.LCS.MIT.EDU
Date: Tue, 4 Apr 89  22:56:20 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@mc
Subject: Consistency

 In the R^3 Report, it is stated that some implementations allow
 (= z1 z2...) which test if all its arguments are numerically
 equal. [p.19]

 I like this, but I wonder why we do not, for consistency, state
 that some implementations will allow multiple argument:

  EQ? EQUAL? EQV?

 After all, they are comparison functions just like `='.

 For that matter, what about:  BOOLEAN? INTEGER? ...
 Or even: CHAR-ALPHABETIC? ...

 ** Or anything else with a `?' in its name! **

 Does this sound like ``Andy Rooney meets RRRS''?

						~Ziggy

 P.S. I'm not just trying to make trouble... I honestly
      wanted to test (eq? x y z) today... really.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 28 Mar 89 19:17:39 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA21021@chamartin.AI.MIT.EDU>; Tue, 28 Mar 89 19:17:19 -0500
Date: Tue, 28 Mar 89 19:17:19 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903290017.AA21021@chamartin.AI.MIT.EDU>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
In-Reply-To: William Clinger's message of Tue, 28 Mar 89 15:34:13 PDT <8903282334.AA10524@fog.cs.uoregon.edu>
Subject: yellow pages
Reply-To: jinx@zurich.ai.mit.edu

    The reason that Ken's ERROR (which corresponds to CERROR in MacScheme)
    can be a procedure rather than a special form is that programmers can
    avoid calling it in a tail-recursive position if think they might want
    to examine the environment of the procedure from which it is called.
    That is, they can write (BEGIN (ERROR ...) #T) instead of (ERROR ...)
    if they want.  I suspect that anyone who prefers a special form to this
    is probably going to be unhappy with Scheme anyway.

I understand that.  That is why I suggested that the error special
form could expand into

((error-procedure <args>)) 

which again guarantees non tail-recursive position.

I disagree, however, with two of the points of the above paragraph:

    I suspect that anyone who prefers a special form to this
	is probably going to be unhappy with Scheme anyway.

I disagree with this sentence for obvious reasons.

							    programmers can
	avoid calling it in a tail-recursive position if think they might want
	to examine the environment of the procedure from which it is called.

The problem is that this choice by the programmer does not leave a
choice to the user of the program (who might be the same person at a
different point in time).  I've often been upset at an earlier version
of myself for flushing state in a program when thinking that I
obviously would never need to examine it.  

I think that having an ERROR procedure which makes it convenient to
flush the computation's state at a point when it should not be flushed
(as far as I'm concerned) is a really bad idea.  I'd much rather have
programmers go out of the way to flush the state at an error than the
other way around, as you suggest.

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 28 Mar 89 18:35:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 28 Mar 89 15:34:38 PDT
Received: by fog.cs.uoregon.edu; Tue, 28 Mar 89 15:34:13 PDT
Date: Tue, 28 Mar 89 15:34:13 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8903282334.AA10524@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
Subject: yellow pages

  (a) The IEEE draft standard should NOT include things that belong in
  the yellow pages. We need to get that set of public, portable programs
  started.  That's Ken's much-needed large library.  Come on gang, it's
  been over two years since Bill Rozas was appointed librarian, and I
  haven't heard of a single contribution. GET WITH IT.

Hear, hear!  Rather than give Ken a hard time, we should thank him
for getting us back to the reason for all this standardization:
so we can write and share portable code.

Rozas volunteered to be librarian for only six months, to get things
started.  It's time for someone else to volunteer, and it's time for
that someone to make lists of what ought to go in the yellow pages
(as Ken has tried to do, but on a bigger scale) and enlist individuals
and companies to contribute those things.  Chris Hanson, for example,
volunteered long ago to contribute a library of string-handling
procedures.  I recently volunteered a portable string->number for the
R4RS syntax.  The new librarian should nag us to do it, and publicize
their availability.

I agree with those who have said that this stuff shouldn't go into the
IEEE standard, at least not now.  Get them into the yellow pages, use
them, and then standardize if appropriate.

I have a few specific comments on Ken's proposals and the discussion
they begat:

There is no such thing as a read/eval/print loop in applications
written using MacScheme+Toolsmith.  The notion of such a thing may
seem natural to a Scheme programmer, but it generally makes no sense
to users of a system written in Scheme.  This shows that the REPL
is part of the programming environment, which we have agreed not to
try to standardize.  The same is true of RESET.

The reason that Ken's ERROR (which corresponds to CERROR in MacScheme)
can be a procedure rather than a special form is that programmers can
avoid calling it in a tail-recursive position if think they might want
to examine the environment of the procedure from which it is called.
That is, they can write (BEGIN (ERROR ...) #T) instead of (ERROR ...)
if they want.  I suspect that anyone who prefers a special form to this
is probably going to be unhappy with Scheme anyway.

There are several semantically distinct notions of structures, each
with its own set of advantages.  Compare, for example, the structures
used in PC Scheme with the system based on structural subtyping that
is distributed with MacScheme 2.0; compare both with the structures
used in the forthcoming book by Friedman, Haynes, Kohlbecker, and
Wand; compare all three with the records proposed last year by Rees.
I think we should first get half a dozen structure packages into the
yellow pages, wait a couple of years, and then see if people prefer
one to the others.

I don't see the need for a conditional compilation facility.  Most
conditionalization can be handled in the load file, and the rest can
be handled with things like

  (define make-bit-vector
    (case **implementation**
      ((macscheme) make-bytevector)
      (else (lambda (size) (make-string size #\0)))))

If the objection to this is the code size for the case expression,
the solution is to wait for the macro package and use a macro instead.
If the objection is that calls to make-bit-vector might not be as
efficient as calls to make-vector or make-bytevector, then I think
that's a different problem that doesn't have much to do with conditional
compilation.

Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 28 Mar 89 18:33:01 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 28 Mar 89 15:32:58 PDT
Received: by fog.cs.uoregon.edu; Tue, 28 Mar 89 15:32:40 PDT
Date: Tue, 28 Mar 89 15:32:40 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8903282332.AA10517@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: transitive arithmetic comparisons

    Jinx:
    ...Comparisons between exact and
    inexact numbers should coerce the exact numbers to inexact...

  Alan:
  If <= is to behave transitively, even on inexact arguments, then you have
  to coerce inexact number to exact numbers in order to perform comparisons.

It depends on the implementation.  Fortunately this is of no concern to the
user, who can rest easy knowing that the arithmetic predicates are transitive
without having to know what the implementors had to go through to make them
so.

In an implementation that represents all exact reals as 32-bit fixnums, and
all inexact reals as 64-bit flonums, then it is correct to coerce exact to
inexact before comparing, as Jinx said.

In an implementation that represents all exact reals as fixnums, bignums, or
ratnums, and all inexact reals as flonums, then it is correct to coerce
inexact to exact before comparing, as Alan said.

In an implementation that represents all exact reals as 32-bit fixnums, and
all inexact reals as 32-bit flonums, then the correct behavior is much more
complicated because there exist fixnums that cannot be coerced to flonums
without loss of accuracy and vice versa.  Likewise for implementations that
represent all exact reals as fixnums or bignums, and all inexact reals as
flonums.  Although algorithms with the correct transitive behavior are a
bit too complicated for me to want to describe here, they exist.

The R4RS specifies only that the arithmetic predicates must be transitive.
It doesn't say how this is to be achieved, since that would require some
assumptions about the particular representations used for exact and inexact
numbers.

Peace, Will

Received: from mbunix.mitre.org (TCP 30003074001) by MC.LCS.MIT.EDU 28 Mar 89 15:52:30 EST
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@huxley.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA09201; Tue, 28 Mar 89 15:51:27 EST
Posted-Date: Tue, 28 Mar 89 15:51:25 EST
Received: by huxley. (4.0/SMI-4.0)
	id AA00405; Tue, 28 Mar 89 15:51:25 EST
Date: Tue, 28 Mar 89 15:51:25 EST
From: ramsdell@huxley.MITRE.ORG (John D. Ramsdell)
Message-Id: <8903282051.AA00405@huxley.>
To: rrrs-authors@mc.lcs.mit.edu
Subject: copyrights
Reply-To: ramsdell@MDF.mitre.org

The new copyright law effective March 1, 1989 states that some
documents have a copyright even if the document does not contain the
words "copyright 1989 by ..." or "Copr 1989 by ...".  If we do not
intend to copyright R5RS, does anyone know what we must do to make it so?
John

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 27 Mar 89 23:15:56 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae05205; 27 Mar 89 19:30 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa05834; 27 Mar 89 19:21 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA17472; Mon, 27 Mar 89 15:33:04 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA01309; Mon, 27 Mar 89 15:35:22 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA15848; Mon, 27 Mar 89 15:33:25 pst
Message-Id: <8903272333.AA15848@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, 
    scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: Re: Portability (long) ...(now short)
In-Reply-To: Your message of Thu, 23 Mar 89 21:18:46 -0500.
	     <8903240218.AA13201@chamartin.AI.MIT.EDU>
Date: 27 Mar 89 15:33:23 PST (Mon)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

    
****************************************
    
        ALIAS is useful in porting code and exists in current implementations
        (PCScheme, Scheme-84).  Yes, all implementation have ways of providing
        syntactic extensions.  The problem is that few of them are the same
        (macro, define-macro, define-syntax, extend-syntax, ...).  I can't write
        ALIAS portably.  
    
    I still find your argument circular.  Please give me an example where
    ALIAS solves anything by itself, ie. without any conditionalization.
    
ALIAS can be used to ease porting of code by obviating the need to go
through text files with an editor doing alpha-conversion `by hand'.  I
guess that I am really impatient to get a uniform syntax system.  If we
have to live with the current situation for another couple of years,
ALIAS and friends can be of some help.  If we get syntax soon, we can
(and should) flush most syntax [although LET, LETREC, etc. would be nice
to keep, moving DO to the Yellow Pages would make quite a few people
happy].

****************************************
    
        BOUND? may be a primitive procedure which accesses the environment of the
        call via agreement between the compiler and runtime system.  Isn't
        requiring it to be a special form overspecification?  
    
    Therefore you would have
    
    (let ((foo 3))
      (bound? 'foo))
    
    return #T
    
    but
    
    (define (check name)
      (bound? name))
    
    and separately compiled
    
    (let ((foo 3))
      (check? 'foo))
    
    return #F?  I don't believe you are really proposing this.  This
    violates all forms of referential transparency that I can think of.

NO!! The above should return #t!  The agreement I was thinking of is use
of registers, shape of environment (ribcage, display, etc.) and so fourth.
If a compiler can recognize BOUND? as constant, it can do the elimination
of the test in the above case and just generate code to return #t.
Likewise for the CHECK case if you change the definition of CHECK to use
DEFINE-CONSTANT and the compiler has access to the seperately compiled
unit's binding information.  

The more interesting question is when the BOUND? check can take place and
in what environment (read, compile, run).  I would prefer to have this
resolved in the compile time environment so that no code is ever
generated to do the test.  This is definately an environment problem
(unless we make such a function a part of the core language [to quote you:
"Yuck!"]).  I guess the real question here is "Is the cure worse than the
disease?".  What I want is a (cheap) way to test for desired
functionality, not just names.  Perhaps we need to wait for a module
system and specification language.

Thanks,
-Ken

    
    
    
    

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 27 Mar 89 16:52:58 EST
Received: from Salvador.ms by ArpaGateway.ms ; 27 MAR 89 13:32:49 PST
Date: Mon, 27 Mar 89 13:32:39 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Portability (long)
In-reply-to: <8903261939.AA07435@mrloog.LA.TEK.COM>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
Message-ID: <890327-133249-13090@Xerox>

I have no objection to attempting to gain concensus on language and library
issues that we believe are well understood.  I believe, however, that many
of the issues you describe are not well understood or are not concerned
with the language or its libraries.  In particular, many of your issues
concern facilities intended for use by a human programmer and not by
programs.

An example of an issue that clearly falls within the language or its
libraries is random access operations on ports for which they make sense,
such as a file input port.

An example of an issue outside of that domain is the notion of a
real-eval-print loop or a ``host system''.  I strongly oppose
standardization of such notions because they are not universal in any
sense.  You claim that you have ``not seen too many Lisps without a Read
Eval Print Loop which has a way of RESETing to the top level and EXITing to
the host system''.  I have seen several, including Xerox Lisp and Symbolics
Genera; in these systems, there is no such thing as a ``host system'' and,
in Xerox Lisp at least, no institutionalized notion of a ``top level'' to
which one might return.

The Scheme language committees should not be concerned with a programmer's
ability maneuver in the user interface of an implementation.  If, in a
particular implementation, the programmer cannot figure out, without
reading the documentation, how to manipulate a read-eval-print loop, it is
not an issue for the committees designing a language.  We are not
attempting to design or standardize upon a user interface.

        I have also not seen any response to, I think, Jinx's point about
using
        extra ``compile'' and ``load'' files that test which implementation
is in
        use and coordinate things appropriately.

    There is *no* standard way of finding out what implementation is
running!

Of course there is: the human setting up the system can simply read the
name on the box containing the software.  Come on, now; how hard can it be
for the human programmer to choose the appropriate system-dependent
compatibility file?

    I usually find some system code I can't recompile
    with (e.g.) VECTOR? integrated

Why is this an issue for standardization?  If you're making changes to
``system code'', by which I assume you mean parts of some particular
implementation, then you're already completely non-portable.  If that
implementation doesn't tell you all of the fancy hacks that they use in
preparing their system code, complain to them, not to the standardization
committee.

   Assuming a syntax system and a yellow pages (Real Soon Now...), the
   minimum I see is the ability to query an implementation to find out its
   name and version (Nice to get Operating and Filesystem likewise and what
   numerics, etc. are supported).

You don't need this in your program.  Let the human do it.

Among your lists of desired interfaces, you include:
    Basic error handling, tracing
    Compiler and Inspector invocation

Error handling is a deep area in which I would be glad to see some
significant work done.  I'm more than willing to consider seriously any
proposal that deals with the issues well.  For example, I would love to see
someone work on discovering the clean kernel of ideas in the
useful-but-baroque Common Lisp condition system (sorry, Kent).  I would, on
the other hand, object strongly to any patchwork solution unless we can get
concensus that it is a part of any ``real'' solution we might later adopt.
I don't want to standardize on short-term hacks.

Tracing and invocation of other implementation-dependent programming
environment facilities is not an appropriate area for standardization.
Programs don't type these commands, humans do; let those humans read that
particular system's documentation, if any.

In conclusion, I am not against the Scheme specification including the
interfaces to certain essentially universal libraries.  I am, however,
opposed to any standardization of the user interface.  In those cases where
standardization is appropriate, I would like to see very precise proposals
that clearly address the complete issue, rather than short-term patches.

	Pavel

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 26 Mar 89 22:03:52 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab14534; 26 Mar 89 21:29 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa23966; 26 Mar 89 21:25 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA18502; Sun, 26 Mar 89 11:40:24 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA10648; Sun, 26 Mar 89 11:42:47 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA07435; Sun, 26 Mar 89 11:39:45 pst
Message-Id: <8903261939.AA07435@mrloog.LA.TEK.COM>
To: Pavel.pa@XEROX.COM
Cc: kend%mrloog.la.tek.com@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU, 
    scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET, kend@mrloog.la
Subject: Re: Portability (long)
In-Reply-To: Your message of Thu, 23 Mar 89 17:25:09 PST.
	     <890323-172519-6244@Xerox>
Date: 26 Mar 89 11:39:43 PST (Sun)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

  
  This whole exercise seems entirely misguided to me.  I have not seen you
  (or anyone) respond well to Morry's objection that any ``appendix''
  constitutes a standard with inertia of its own.

An appendix will have inertia just as any large body of code (of any
sort) has inertia.  I don't believe that the inertia will be as great as
C's standard library because Scheme already has i/o and string=?, etc.
which C needed to be viable.  Scheme is pretty viable on its own.  In
addition, I expect things to change.  R2RS->R3RS had some interesting
changes.  Number syntax will change when (if) we can agree on ways to
deal with approximations to real numbers.

My proposal arises out of my perception that some names and functions are
widely used and are diverging.  I think that defining a language without
some thought of its enviromnent is a bit like Algol without i/o.  We
should not do much now, but there are some things that we do have
experience with.  I have never seen a file system without the idea of a
file pointer designating a position within a file (Pascal got in trouble
with exactly this when they belatedly had to standardize).  I have not
seen too many Lisps without a Read Eval Print Loop which has a way of
RESETing to the top level and EXITing to the host system.  I don't need a
REPL to program my toaster-oven, but I do use them in many Schemes (T,
MacScheme. PCScheme, Skim, AmigaScheme and XScheme this last year) and
would like to be able to trust a few things not to change.  I feel that
there is a need for discussion on the topics raised because the rate of
convergence for the Scheme community is very slow {e.g. numerics, macros}.
The Structure and Interpretation text is being used in over 125
universities last time I heard and I am concerned that issues be worked
on and solved before they become ISSUES.


  I have also not seen any response to, I think, Jinx's point about using
  extra ``compile'' and ``load'' files that test which implementation is in
  use and coordinate things appropriately.

There is *no* standard way of finding out what implementation is running!

  Any publication of a standard interface to certain facilities tends to
  reduce experimentation among implementations.  Such constraints should only
  be imposed on facilities with which we collectively have significant
  experience and on which we have reached consensus about what is The Right
  Thing.

Agreed.  The question is of balance and timing.  I don't expect the
FORMAT function to have "~A" format string cause a program to abort.  I
expect FORMAT (if it exists) to DISPLAY the next argument.  I agree with
your statement.  I think that in some areas we can reach a consensus.

  I think that detailed discussion of your many proposals is premature until
  you or others have more adequately justified the point of the whole
  endeavor.

Well, there are some things it would be nice to do.  Assuming that a
syntax system comes along soon, we can certainly do without ALIAS and
friends.  To do a structure or object system a way of adding disjoint
types would be nice.  I usually find some system code I can't recompile
with (e.g.) VECTOR? integrated, and I do get tired of rewriting a printer
to make sure something prints as #<structure foo> rather than a
strange-looking vector.  I can't write a native or byte-code compiler
without the ability to do binary i/o.  I can't do a portable interactive
text editor without the ability to set up software interrupt handlers.
Likewise, some sort of ERRORSET would be helpful in catching user runtime
errors in an editor rather than putting a user in some random debug REPL
in a raw mode tty.  I have yet to see a runtime system library of any
size which did not supply a set of SORT functions or a RANDOM number
generator or some form of FORMATted output.  Yes, I can do my own reader
for strings, but STRING-PORTs are much more convenient.

[OK, so I have a more-than-full-time job and outside interests.  There is
a lot that I want.  And I am impatient.  I want great things.  I want
discussions in certain areas so that we will have convergence.]

**"What, if any, of this is appropriate for the IEEE Scheme Standard at
this time?"**

Assuming a syntax system and a yellow pages (Real Soon Now...), the
minimum I see is the ability to query an implementation to find out its
name and version (Nice to get Operating and Filesystem likewise and what
numerics, etc. are supported).  

I would very much like to see (and feel strongly about) having specific
problems addressed in a non-binding appendix (not part of the language
standard) and as interfaces only:
    Binary i/o (including file positioning); <mumble>-ports
    Formatted output (FORMAT)
    Basic error handling, tracing
    Compiler and Inspector invocation
    Date and Time

I would be happy to see: (interfaces to)
   Ability to add disjoint types (to support Structures, Objects)
   Commonly used functionality.


-------------------------
Thank you for speaking up.
-Ken			kend@mrloog.LA.TEK.COM

Received: from etana.funet.fi (TCP 20065400401) by MC.LCS.MIT.EDU 25 Mar 89 08:45:28 EST
Received: by etana.funet.fi; id AA27648; Wed, 25 Jan 89 15:36:40 +0200
Received: by korppi.tut.fi (4.0/10.6.master) id AA11003; Sat, 25 Mar 89 15:45:07 +0200
Message-Id: <8903251345.AA11003@korppi.tut.fi>
Date: Sat, 25 Mar 89 15:45:07 +0200
From: jh@tut.fi (Juha Hein{nen)
To: mkatz@sesame.stanford.edu
Cc: gyro@kestrel.ARPA, Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu,
        scheme-standard@kleph.ai.mit.edu
In-Reply-To: Morris Katz's message of Fri, 24 Mar 89 11:39:36 PST <8903241939.AA16254@sesame.Stanford.EDU>
Subject: Standardization of libraries

   dependent.  Lets get syntactic extensions standardized, and the
   rest will come along naturally.

I fully agree with this.  Few interesting modules can be written
without a syntactic extension mechanism.  Until Scheme has one, it
can't become a real programming language with good module library and
large commercial user community.

-- Juha Heinanen

Received: from polya.Stanford.EDU (TCP 4402000240) by MC.LCS.MIT.EDU 24 Mar 89 16:57:26 EST
Received: from Sesame.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA16188; Fri, 24 Mar 89 11:39:28 -0800
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA16254; Fri, 24 Mar 89 11:39:36 PST
Date: Fri, 24 Mar 89 11:39:36 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8903241939.AA16254@sesame.Stanford.EDU>
To: gyro@kestrel.arpa
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu,
        scheme-standard@kleph.ai.mit.edu
In-Reply-To: Scott B. Layson's message of Fri, 24 Mar 89 03:37:33 PDT <8903241137.AA18718@kestrel.arpa>
Subject: Standardization of libraries

   Date: Fri, 24 Mar 89 03:37:33 PDT
   From: gyro@kestrel.arpa (Scott B. Layson)

      Date: Thu, 23 Mar 89 17:25:09 PST
      From: Pavel.pa@Xerox.COM

      This whole exercise seems entirely misguided to me.  I have not seen you
      (or anyone) respond well to Morry's objection that any ``appendix''
      constitutes a standard with inertia of its own.

   I don't think the exercise is *entirely* misguided.  Unless we take
   the attitude that we literally don't care whether we have a user
   community or not, we are going to have to pay some attention to the
   needs of that community.  The question is what kind, and how much, and
   at what cost to our goal of facilitating exuberant experimentation
   among implementors.

   The problem, of course, is that there is a natural antagonism between
   encouraging ferment and the needs of users for stability.  I daresay
   the general sentiment is that we consider ferment much more important
   than do, say, the Common Lisp designers.  (I don't think this goes
   without saying -- I could make a case for the point of view that if we
   want Scheme to be really widely used, we should go into "product
   support" mode as quickly as possible -- but for the moment I will take
   it as a given that our priority is ferment.)

   So then the question becomes, is there any way we can have ferment and
   still give our users what they need?  I think there might be, though
   it will take some effort to do, and that it will look roughly like
   this:

    -- In the Scheme standard (this applies equally to the RnRS
       leading-edge standard and the IEEE "trickle-down" standard) we
       make absolutely every attempt to specify the minimum language in
       which all else can be written.  In short, we want the standard to
       specify a basis set of programming constructs, and nothing else.

    -- This means that *anything* that can be written in terms of the
       standard constructs must not be part of the standard.  This
       includes the kinds of things we have been discussing: top level
       loops, error reporters, etc.

    -- To make it possible to write portable programs that make use of
       such facilities, we resort not to the static approach represented
       by a document, but rather to a dynamic approach: an official
       module registration facility.

   The idea of the module registration facility is that anyone who thinks
   they have a module (subsystem, collection of functions, whatever you
   want to call it) that would be of general interest can register it,
   that is, make it publicly available under a unique name.  The module
   could be something completely new, or it could be only a variation
   (preferably not a totally trivial variation) on some other registered
   module.  Once a module is published, the only allowed changes to it
   are bug fixes, compatible performance improvements, and upwardly
   compatible extensions.

   Users, then, need only list the modules to be used by any given
   program.  Once the program is written, the user never need update it
   to use more recently released modules, although that is always an
   option.  Implementors need not concern themselves with modules at all,
   except insofar as we may decide to add a construct or two to the core
   language to support their use.

   Note that when I say "a module registration facility" I don't mean a
   facility in the linguistic sense, like Common Lisp's PROVIDE /
   REQUIRE; I mean an office with a budget and a staff, you know, humans.
   Well, with luck it would only take a fractional human.  The tasks
   would be 1) to assign the unique module names; 2) to maintain a
   library containing the source code for each registered module; and 3)
   to fill orders for copies of said source code.

   It's an institutional rather than linguistic solution, but then I
   think the problem is more a social one than a technical one to start
   with.

   Comments?
     Scott


At Snowbird we already essentially created such a facility.  We called it a
library.  Jinx agreed to be the librarian for the first 6 months (I believe).
Users were encouraged to contribute modules to the library (with a preference
for those which could be run under many different versions of Scheme).  All
information in the library was to be available by anonymous ftp and possibly by
UUCP.  It seems to me that the reason that the library has not taken off is
that we still lack a standard mechanism for creating syntactic extensions.
This makes creating code which is executable on many different implementations
of Scheme very difficult.  It should be that any module should be able to be
composed of a series of segments (files) with only one of them being
implementation dependent.  Lets get syntactic extensions standardized, and the
rest will come along naturally.
					Morry Katz
					katz@polya.stanford.edu

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 24 Mar 89 10:04:19 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab07340; 24 Mar 89 9:46 EST
Received: from cs.brandeis.edu by RELAY.CS.NET id ad05919; 24 Mar 89 9:25 EST
Received: by cs.brandeis.edu (14.2/6.0.GT)
	id AA11239; Fri, 24 Mar 89 08:29:35 est
Date: Fri, 24 Mar 89 08:29:35 est
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Fri, 24 Mar 89 08:29:35 est
To: kend%mrloog.la.tek.com.2@cs.brandeis.edu
Cc: rrrs-authors%mc.lcs.mit.edu.2@cs.brandeis.edu, 
    scheme-standard%kleph.ai.mit.edu.2@cs.brandeis.edu
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 17 Mar 89 17:07:16 PST (Fri) <8903180107.AA03798@mrloog.LA.TEK.COM>
Subject: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
Reply-To: JMiller%cs.Brandeis.edu@RELAY.CS.NET

Despite my vow never (well, hardly ever) to send mail these lists,
I'll take a whack at Ken's portability proposal.  My concerns:

(a) The IEEE draft standard should NOT include things that belong in
the yellow pages. We need to get that set of public, portable programs
started.  That's Ken's much-needed large library.  Come on gang, it's
been over two years since Bill Rozas was appointed librarian, and I
haven't heard of a single contribution. GET WITH IT.

(b) Neither document should attempt to constrain or describe the
interactive environment.  The standard should be for a programming
language, not its environment.

(c) The IEEE standard should not include special forms that are
trivially implemented on top of an extend-syntax type of macro
facility and the proposed standard language.  Macros are within sight
now (they will be in R4RS or R4+epsilonRS) and can be adopted
wholesale into the IEEE standard after they have been implemented and
studied thoroughly.

So:

(1) I believe FORMAT, RANDOM, SORT, and SORT! can and should be
implemented as yellow pages procedures.  Perhaps MIT will contribute
the latter three (I think their versions are portable).

(2) I endorse the proposal (Bill Rozas?) of standardizing port
constructors, but in R5RS, not IEEE.  In the interim, let's have a YP
format for use in IEEE Scheme that generates strings.

(3) I agree with Bill that user's shouldn't be aided in using (RESET)
from within a program; it is part of the user interface for dealing
with the system.

(4) I also agree with Bill that errors should be able to be
intercepted at runtime.  This is the whole area of exception handling,
and I don't believe that we're likely to get much agreement in this
area quickly.  There are, however, cogent arguments that the
environment in which the error occurs must be available for error
handling, and this dictates special forms rather than procedures
(unless someone seriously proposes putting in first-class
environments).  Thus, I believe that ERROR and FATAL-ERROR should be
reserved words, with the understanding that implementations will often
provide either a special form or a procedure of the "signature"
suggested by Ken.  >> I SUGGEST THAT BOTH IEEE AND R5RS RESERVE THESE
NAMES. <<

(5) The following are all environment issues and shouldn't be
addressed in the standard: INSPECT, TRACE, UNTRACE, SUSPEND, AUTOLOAD.

(6) I don't like ALIAS, but I'll just claim that it ought to be a
macro built with the soon-to-be syntactic closure mechanism.

(7) COMMENT is a fine idea, but it's a trivial macro.  So are UNLESS,
WHEN, and COMMENT-WHEN.

(8) I hate to say it, but don't forget about time zones and the
international date line.  If you want to do date and times at all,
let's add the "right" primitive and have YP to do the rest.

(9) I don't even want to think about what I'd like RUNTIME to mean in
MultiScheme.  If you propose a microsecond real clock for the base of
the date and time stuff, would that suffice?

(10) I'm not ready to byte off (sorry) your binary stuff.  I don't see
any reason to recommend byte vectors to all implementations, and I
certainly don't believe in conversion between strings and byte
vectors.

(11) I think you've already seen arguments about BOUND? and the
DEFINE-IF- stuff that are powerful enough to suggest we aren't ready
for standards here.

(12) Structures are great.  But (a) can we do them with macros, and
(b) can we come up with a more complete specification?  I think the
R5RS should deal with this one.

--Jim Miller

Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 24 Mar 89 06:37:16 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
	id AA18718; Fri, 24 Mar 89 03:37:33 PDT
Date: Fri, 24 Mar 89 03:37:33 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903241137.AA18718@kestrel.arpa>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard@kleph.ai.mit.edu
In-Reply-To: Msg of Thu, 23 Mar 89 17:25:09 PST from Pavel.pa@Xerox.COM
Subject: Standardization of libraries

   Date: Thu, 23 Mar 89 17:25:09 PST
   From: Pavel.pa@Xerox.COM
   
   This whole exercise seems entirely misguided to me.  I have not seen you
   (or anyone) respond well to Morry's objection that any ``appendix''
   constitutes a standard with inertia of its own.

I don't think the exercise is *entirely* misguided.  Unless we take
the attitude that we literally don't care whether we have a user
community or not, we are going to have to pay some attention to the
needs of that community.  The question is what kind, and how much, and
at what cost to our goal of facilitating exuberant experimentation
among implementors.

The problem, of course, is that there is a natural antagonism between
encouraging ferment and the needs of users for stability.  I daresay
the general sentiment is that we consider ferment much more important
than do, say, the Common Lisp designers.  (I don't think this goes
without saying -- I could make a case for the point of view that if we
want Scheme to be really widely used, we should go into "product
support" mode as quickly as possible -- but for the moment I will take
it as a given that our priority is ferment.)

So then the question becomes, is there any way we can have ferment and
still give our users what they need?  I think there might be, though
it will take some effort to do, and that it will look roughly like
this:

 -- In the Scheme standard (this applies equally to the RnRS
    leading-edge standard and the IEEE "trickle-down" standard) we
    make absolutely every attempt to specify the minimum language in
    which all else can be written.  In short, we want the standard to
    specify a basis set of programming constructs, and nothing else.

 -- This means that *anything* that can be written in terms of the
    standard constructs must not be part of the standard.  This
    includes the kinds of things we have been discussing: top level
    loops, error reporters, etc.

 -- To make it possible to write portable programs that make use of
    such facilities, we resort not to the static approach represented
    by a document, but rather to a dynamic approach: an official
    module registration facility.

The idea of the module registration facility is that anyone who thinks
they have a module (subsystem, collection of functions, whatever you
want to call it) that would be of general interest can register it,
that is, make it publicly available under a unique name.  The module
could be something completely new, or it could be only a variation
(preferably not a totally trivial variation) on some other registered
module.  Once a module is published, the only allowed changes to it
are bug fixes, compatible performance improvements, and upwardly
compatible extensions.

Users, then, need only list the modules to be used by any given
program.  Once the program is written, the user never need update it
to use more recently released modules, although that is always an
option.  Implementors need not concern themselves with modules at all,
except insofar as we may decide to add a construct or two to the core
language to support their use.

Note that when I say "a module registration facility" I don't mean a
facility in the linguistic sense, like Common Lisp's PROVIDE /
REQUIRE; I mean an office with a budget and a staff, you know, humans.
Well, with luck it would only take a fractional human.  The tasks
would be 1) to assign the unique module names; 2) to maintain a
library containing the source code for each registered module; and 3)
to fill orders for copies of said source code.

It's an institutional rather than linguistic solution, but then I
think the problem is more a social one than a technical one to start
with.

Comments?
  Scott

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Mar 89 21:17:31 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA13201@chamartin.AI.MIT.EDU>; Thu, 23 Mar 89 21:18:46 -0500
Date: Thu, 23 Mar 89 21:18:46 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903240218.AA13201@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET,
        kend%mrloog.la.tek.com@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 23 Mar 89 15:47:20 PST (Thu) <8903232347.AA09084@mrloog.LA.TEK.COM>
Subject: Portability (long)
Reply-To: jinx@zurich.ai.mit.edu

    My recollection is that Dan wants a global variable bound to the
    continuation caught at the top level. 

That is pretty much what ABORT-TO-NEAREST-REPL is, except that instead
of having the REPL do

(call-with-current-continuation
  (lambda (here)
    (fluid-let ((RESET here))
      <code of repl>)))

it is done with (note extra parens)

((call-with-current-continuation
  (lambda (here)
    (fluid-let ((ABORT-TO-NEAREST-REPL here))
      (let ((val <code of repl>))
        (lambda () val))))))

so that the thunk will be executed when "fed" to ABORT-TO-NEAREST-REPL.

Maybe the name is confusing, so let's propose a compromise:

RESET is a procedure of 0 or 1 arguments.  When invoked with no
arguments, it does what you want.  When invoked with 1 argument, it
"resets" to the read eval print loop, and within this context, it
invokes its argument, which is what ABORT-TO-NEAREST-REPL does.

					Most implementations have a RESET
    function now.  Describing RESET library interface describes what is
    typically there now.  Adding ABORT-TO-NEAREST-REPL to the library
    interface (given the things that are missing) is, I feel, premature.
    ABORT-TO-NEAREST-REPL is a proposal for RnRS.

Having ABORT-TO-NEAREST-REPL (under whatever name) makes zero-argument
RESET unnecessary, and I find zero-argument RESET distasteful.

****************************************
    Currently there are error functions defined with 2 different behaviors.
    One acts like 
     (define (ERROR msg . args) (format #t message args) (reset)).
    The other acts like
     (define (ERROR msg . args) (format #t message args) (debug)).

The ERROR special form in MIT Scheme does neither.  In the absence of
any condition handlers, it opens up a NEW read eval print loop in the
environment of the error.  The debugger can be invoked from there, or
a procedure can be invoked to abort to the previous read eval print
loop.  In spirit it is more like the second, but does not really fit.

    Different Scheme implementrations supply one form or both forms and both
    forms are called ERROR by some implementations.  I called the first one
    FATAL-ERROR and the second one ERROR.  Perhaps I should have just used
    the MacScheme convention (ERROR and CERROR).  I would like a consistent
    naming convention across implementations which distinguishes behavior.
    Please propose one (How about NOISY-RESET and ERROR?).

I understand this.  I don't object to the name FATAL-ERROR only, I
object to the concept.  I don't believe there are such beasts as
non-recoverable errors.  I think ERROR should imply recovery, and I
will object to standardizing on anything else.  Although the
"functionality" of your FATAL-ERROR can be built on top of RESET, or
ABORT-TO-NEAREST-REPL, I don't think that users should be encouraged
to write programs that randomly abort rather than let the user examine
their state and proceed the computation after fixing whatever is
wrong.

****************************************

    ALIAS is useful in porting code and exists in current implementations
    (PCScheme, Scheme-84).  Yes, all implementation have ways of providing
    syntactic extensions.  The problem is that few of them are the same
    (macro, define-macro, define-syntax, extend-syntax, ...).  I can't write
    ALIAS portably.  

I still find your argument circular.  Please give me an example where
ALIAS solves anything by itself, ie. without any conditionalization.

****************************************

    Yes, it would be nice to stay out of port and register sizes.  It makes
    writing system code somewhat difficult, however.  Are you proposing a
    parameterized routine? e.g. (WRITE-BINARY <exact-integer> . <num-bits>)?
    I think that this special case of binary-i/o is helpful.  The general
    case is hard to specify well.

I'd much rather go for WRITE-BINARY than for WRITE-BYTE.

****************************************

    BOUND? may be a primitive procedure which accesses the environment of the
    call via agreement between the compiler and runtime system.  Isn't
    requiring it to be a special form overspecification?  

Therefore you would have

(let ((foo 3))
  (bound? 'foo))

return #T

but

(define (check name)
  (bound? name))

and separately compiled

(let ((foo 3))
  (check? 'foo))

return #F?  I don't believe you are really proposing this.  This
violates all forms of referential transparency that I can think of.


							I think that we
    could really make do with BOUND-AT-TOP-LEVEL? or some such.  

Assuming we can all get to agree on what "top-level" means.


								I think
    it best to flush DEFINE-IF-<mumble>, but testing for existance of a
    definition without generating a runtime error is a necessity.

I don't disagree for the need for BOUND?.  I just object to a
procedural definition which does not make sense.




Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 Mar 89 20:27:39 EST
Received: from Salvador.ms by ArpaGateway.ms ; 23 MAR 89 17:25:19 PST
Date: Thu, 23 Mar 89 17:25:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Portability (long)
In-reply-to: <8903232347.AA09084@mrloog.LA.TEK.COM>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard@kleph.ai.mit.edu
Message-ID: <890323-172519-6244@Xerox>

Ken says, ``I have only heard from 3 people and would appreciate more
opinions and comments.''

You asked for it.

This whole exercise seems entirely misguided to me.  I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own.  Ziggy's idea of putting a
prefix on each name seems beside the point; if I'm going to use these
``portable'' constructs, then I'm going to hardwire these names into my
code and resist changes to their semantics.  I don't see what changing the
names will do, unless you intend that every implementation retain every
version of every facility, so that each implementation would have to carry
along NB4-UNLESS, NB5-UNLESS, etc. in perpetuity.  That's clearly
unacceptable.

I have also not seen any response to, I think, Jinx's point about using
extra ``compile'' and ``load'' files that test which implementation is in
use and coordinate things appropriately.  Of course, one need not actually
use files for such things; humans are reasonably good at picking out the
one ``system-dependent'' file of code for their implementation and using
that along with the bulk of the software system.  If, indeed, as you state,
most implementations have facilities similar to what you've described (in
some cases, I doubt this very much), then such ``system-dependent'' files
will be terribly easy to write.

Any publication of a standard interface to certain facilities tends to
reduce experimentation among implementations.  Such constraints should only
be imposed on facilities with which we collectively have significant
experience and on which we have reached consensus about what is The Right
Thing.

I think that detailed discussion of your many proposals is premature until
you or others have more adequately justified the point of the whole
endeavor.

	Pavel

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 23 Mar 89 19:47:30 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa27517; 23 Mar 89 19:14 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa28069; 23 Mar 89 19:04 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA08245; Thu, 23 Mar 89 15:47:01 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA12973; Thu, 23 Mar 89 15:49:24 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA09084; Thu, 23 Mar 89 15:47:23 pst
Message-Id: <8903232347.AA09084@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, 
    scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET, 
    kend%mrloog.la.tek.com@RELAY.CS.NET
Subject: Re: Portability (long)
In-Reply-To: Your message of Tue, 21 Mar 89 22:47:37 -0500.
	     <8903220347.AA09548@chamartin.AI.MIT.EDU>
Date: 23 Mar 89 15:47:20 PST (Thu)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

  
  	 (ABORT-TO-NEAREST-REPL <thunk>)
  	...
  
      How is the "nearest repl" known to the runtime system?  How does a
      Scheme system recognize that a function is a (possibly user written)
      repl?  I don't have a problem with implementing RESET or FATAL-ERROR
      this way, but why standardize this function as a library routine?
  
  The idea is that the runtime system provides facilities for building
  repls which interact with these abort procedures (there are many in
  MIT Scheme), and can provide additional functionality.  While this
  procedure is useful for writing things like RESET, it is useful in its
  own right: interrupt characters cause invocations of such procedures
  in MIT Scheme.  Dan Friedman needs something like
  ABORT-TO-NEAREST-REPL for some of the stuff he does as well.

My recollection is that Dan wants a global variable bound to the
continuation caught at the top level.  Most implementations have a RESET
function now.  Describing RESET library interface describes what is
typically there now.  Adding ABORT-TO-NEAREST-REPL to the library
interface (given the things that are missing) is, I feel, premature.
ABORT-TO-NEAREST-REPL is a proposal for RnRS.

**********************************************************
Currently there are error functions defined with 2 different behaviors.
One acts like 
 (define (ERROR msg . args) (format #t message args) (reset)).
The other acts like
 (define (ERROR msg . args) (format #t message args) (debug)).

Different Scheme implementrations supply one form or both forms and both
forms are called ERROR by some implementations.  I called the first one
FATAL-ERROR and the second one ERROR.  Perhaps I should have just used
the MacScheme convention (ERROR and CERROR).  I would like a consistent
naming convention across implementations which distinguishes behavior.
Please propose one (How about NOISY-RESET and ERROR?).

**************************************************************

  
  	 5) ERROR must be a special form in order to get the environment of
  	 the "call".  In MIT Scheme, the ERROR special form expands into
  	 something like
  	 (ERROR-PROCEDURE (the-environment) <message> . <irritants>)
  
      ERROR works just fine as a procedure in many systems (Chez Scheme, T,
      and MacScheme).  The fact that MIT Scheme has a non-standard way to
      access the environment makes it convenient for ERROR to be a special
      form in MIT Scheme.  I would really prefer that you propose an
      standard environment mechanism if you want to insist that ERROR must
      be a special form (or better yet, a standard error handling
      mechanism).  I really prefer procedures to special forms. 
  
  I'm very confused.  As far as I know, all correct scheme
  implementations must be properly tail recursive, and this is what forces
  error to be a special form.  For example, in ...

ERROR *is* a procedure in Chez Scheme, T, and MacScheme.  Yes, tail
recursion loses in the cases you mention.  I understand the
implementation considerations.  I will not propose that those who
implement ERROR as a function be forced to change that implementation to
be a special form.  You are free to convince them.

************************************************************************
Yes, TRACE was underspecified.  TRACE and UNTRACE should take values.
(I said that).

************************************************************************
  	 7) ALIAS: Why can't you just use (define <alias> <original>) ?
  
      This is hard to do with special forms.
  
      ...
  
      The reason for these bits of syntax is that we need to solve the
      portability problems now and we do not yet have syntactic extensions.
      ...
  
  Although I agree with the gist of your argument, I don't see how this
  applies to ALIAS.  Either you have a special form in the first place
  which you are providing an alias for, or you do not.  If you have it,
  you can use the original.  If you don't, ALIAS won't solve your
  problem: In order for ALIAS to be of any help in portability, you need
  conditional compilation or conditional loading according to
  implementation.  Whatever you use to discriminate according to
  implementation, you can use to provide definitions of the "missing"
  special forms using each implementation's syntactic extension
  facilities.  As far as I know, all implementations have ways of
  providing syntactic extensions.
  
ALIAS is useful in porting code and exists in current implementations
(PCScheme, Scheme-84).  Yes, all implementation have ways of providing
syntactic extensions.  The problem is that few of them are the same
(macro, define-macro, define-syntax, extend-syntax, ...).  I can't write
ALIAS portably.  

*************************************************************************
  
  	 13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
  
      So you want 3..258?  I think that silent masking of overflow would be
      pretty random. 
  
  I meant that 8 bit bytes are pretty arbitrary.  It would be nice to be
  able to read in (for example) 16 bit quantities, 32 bit quantities,
  etc.  Furthermore, although rare, there are still machines around that
  are not based on 8 bit bytes, and they may become popular again in the
  future.  I would hate to see current hardware praxis getting into
  the language.
  
Yes, it would be nice to stay out of port and register sizes.  It makes
writing system code somewhat difficult, however.  Are you proposing a
parameterized routine? e.g. (WRITE-BINARY <exact-integer> . <num-bits>)?
I think that this special case of binary-i/o is helpful.  The general
case is hard to specify well.

**********************************************************************
...

BOUND? may be a primitive procedure which accesses the environment of the
call via agreement between the compiler and runtime system.  Isn't
requiring it to be a special form overspecification?  I think that we
could really make do with BOUND-AT-TOP-LEVEL? or some such.  I think
it best to flush DEFINE-IF-<mumble>, but testing for existance of a
definition without generating a runtime error is a necessity.

**********************************************************************

Unless there are strong objections I will flush DEFINE-IF-<mumble>.

************

I have only heard from 3 people and would appreciate more opinions and
comments.

Thanks,
-Ken		kend@mrloog.LA.TEK.COM

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Mar 89 18:51:58 EST
Received: from VX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 MAR 89  18:49:10 EST
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA01876@VX.LCS.MIT.EDU>; Thu, 23 Mar 89 18:50:31 est
Date: Thu, 23 Mar 89 18:50:31 est
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net, mkatz@sesame.stanford.edu
Subject: Re:  "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
Cc: kend@mrloog.la, rrrs-authors@mc.lcs.mit.edu,
        scheme-standard%kleph.ai.mit.edu@relay.cs.net

If you are worried about non-binding appendices being interpreted as binding, then
you could always prefix the non-binding forms with (say) NB-<mumble>.  One could
also state (in small print) that some implementations may provide equivalent
forms that omit the NB prefix but this is NOT portable.

Future iterations could increment this prefix... say since the first standard is
tied to Revised^4 Scheme, maybe use NB4-<mumble>.

If the appendix always says NB4-<mumble> and NEVER says just <mumble> anywhere
then nobody can grumble if you later redefine <mumble>.

That's my two cents.					~Ziggy


Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 23 Mar 89 12:23:14 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA14594; Thu, 23 Mar 89 09:20:39 PST
Date: Thu, 23 Mar 89 09:20:39 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903231720.AA14594@sesame.Stanford.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard%kleph.ai.mit.edu@relay.cs.net,
        kend@mrloog.la
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 22 Mar 89 21:50:21 PST (Wed) <8903230550.AA01844@mrloog.LA.TEK.COM>
Subject: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw

   Date: 22 Mar 89 21:50:21 PST (Wed)
   From: kend%mrloog.la.tek.com@RELAY.CS.NET


   Ken Dickey:---(New)--------------------------------------------------V

(text ommitted)

   There are many people like myself who are in a commercial environment and
   wish to use Scheme.  Unless Scheme can be shown to be a portable language
   which tackles commercial problems we are condemned to use C++ or some
   other abomination.  It is my belief that if the above issues are not
   addressed in the IEEE Scheme Standard, usage of the language will be
   crippled.  Standardizing interfaces to functionality which has existed
   for some time in many implementations in a non-binding appendix seems to
                                              ^^^^^^^^^^^^^^^^^^^^
   me the most conservative way of doing so.  Conditional compilation
   /interpretation in some form seems to be the major piece of work, but I
   see it as crucial to the success of the Scheme language (I am not giving
   up my evenings doing this just to get flamed).

   -Ken			kend@mrloog.LA.TEK.COM

There is no such thing as a non-binding appendix as far as I am concerned.
A non-binding appendix is a little like saying stdio isn't part of C.
Kernighan and Ritchie make this distinction in "The C Programming Language",
but from a practical standpoint it is moot.  What are those in favor going to
say if in 6 months a group of us want to change the definitions in the
non-binding appendix in order to make what we believe are improvements?  If you
can honestly say that I will not here any objections on the grounds that we
have already published a different version, then I guess the appendix really is
non-binding; however, I seriously doubt this.  I suspect that it is time for
those of us who are interested in programming language development, as opposed
to product support, to go off and work on another language and let you codify
Scheme. 

					Morry Katz
					katz@polya.stanford.edu

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 23 Mar 89 01:26:39 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae14075; 23 Mar 89 1:14 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa16647; 23 Mar 89 1:10 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA15248; Wed, 22 Mar 89 21:51:00 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA23251; Wed, 22 Mar 89 21:53:26 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA01844; Wed, 22 Mar 89 21:50:23 pst
Message-Id: <8903230550.AA01844@mrloog.LA.TEK.COM>
To: Morris Katz <mkatz%sesame.stanford.edu@RELAY.CS.NET>
Cc: rrrs-authors@MC.LCS.MIT.EDU, 
    scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET, kend@mrloog.la
Subject: Re: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
In-Reply-To: Your message of Wed, 22 Mar 89 09:33:57 PST.
	     <8903221733.AA13463@sesame.Stanford.EDU>
Date: 22 Mar 89 21:50:21 PST (Wed)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

Rather than indent to the limit, I am breaking things up a bit...

JINX (Guillermo Rozas):---------------------------------------------V

	2) I think it's premature to standardize on something like this for
	IEEE.  Proposals along these lines should certainly be considered for
	R5RS.

Ken Dickey:---------------------------------------------------------V

   On the contrary, we need to standardize library issues as soon as
   possible to keep divergence from preventing portability.  The IEEE
   standard is a good place for this.  I really would rather see only
   *language* issues in RnRS.  Most languages standardize too late--after
   implementations have significantly diverged--and there is hell to pay as
   each implementor tries to get *his* dialect as *the* standard (e.g.
   ATLAS).  Currently, we have a portable language, but not portable code.
   I believe that there is sufficient practical experience to have a
   standard interface to common functionality and that the IEEE standard
   needs such an interface to be viable. 

Morry Katz:---------------------------------------------------------V

It seems that the situation that many of us feared is already coming to pass.
I see here a justification for why standardization should drive language design
rather than visa versa.  Let us remember that as difficult as it is to
standardize after peoples paths have diverged, it is even more difficult to
unstandardize a mistake.  I would oppose standardization of any feature that
has not been experimented with in its proposed form for standardization by the
Scheme community for at least 6 months.  DON'T RISK STANDARDIZATION OF
POTENTIAL BUGS.

Ken Dickey:---(New)--------------------------------------------------V

I guess I need to be more clear.  I distinguish between a language and a
library.  I am not proposing any changes to the Scheme language.  I am
proposing *optional* library interfaces to either (1) enable code
portability between implementations or (2) codify common usages.  In
class (1) I am interested in obtaining the functionality in the best
possible way.  In class (2) I don't want any new features or
functionality, but I do want an interface--when implemented--to have the
same parameters and semantics.  {*If* someone implements UNLESS, I want
(UNLESS <test> <exp>...), not some randomness.  UNLESS has been used for
years--I didn't make it up}.

The interfaces (functions or special forms in this context) I consider
class (2) are:
	pretty-print
	reset
	unless
	when
	random
	sort
	sort!
	suspend
	autoload
	define-structure
I have rarely seen an implementation without them.

Other interfaces are included to cure specific problems: to obtain basic
implementation information, format output, do basic error handling,
tracing and environmental inspection, specialization (alias,
define-if-<mumble>, comment-when), benchmarking (date & time functions),
and binary-i/o (including buffers).  With the exception of the
define-if-<mumble> and comment-when (and I would really like to see
alternate proposals for these), any differences in interface from what
most implementations have had for years is purely cosmetic--there is
nothing fundamentially new here.
  
There are many people like myself who are in a commercial environment and
wish to use Scheme.  Unless Scheme can be shown to be a portable language
which tackles commercial problems we are condemned to use C++ or some
other abomination.  It is my belief that if the above issues are not
addressed in the IEEE Scheme Standard, usage of the language will be
crippled.  Standardizing interfaces to functionality which has existed
for some time in many implementations in a non-binding appendix seems to
me the most conservative way of doing so.  Conditional compilation
/interpretation in some form seems to be the major piece of work, but I
see it as crucial to the success of the Scheme language (I am not giving
up my evenings doing this just to get flamed).

{I am sensitive to your concerns, but I don't think that for the readers
of this group conditional specialization is such a large problem that it
can't be addressed.  Given the time frame of the standards process, we
may have 6 months of implementation experience by the time the standard
is published}.

****************************************

Morry Katz:----------------------------------------------------------

When someone is proposing new functionality ...

Ken Dickey:-(new)---------------------------------------------------

I recant.  ABORT->NEAREST, MAKE-<direction>-PORT and friends belong as
proposals to RnRS.

***************************************

I suggest we seperate:
    [A] Arguments to keep or scrap the library proposal as a whole.
and [B] Cleanup, clarifications, or alternate interface proposals for
        specific functionality.

Thanks for the input,
-Ken			kend@mrloog.LA.TEK.COM

Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 22 Mar 89 12:35:59 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA13463; Wed, 22 Mar 89 09:33:57 PST
Date: Wed, 22 Mar 89 09:33:57 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903221733.AA13463@sesame.Stanford.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: jinx@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu,
        scheme-standard%kleph.ai.mit.edu@relay.cs.net
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 21 Mar 89 18:05:49 PST (Tue) <8903220205.AA22716@mrloog.LA.TEK.COM>
Subject: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw

   Date: 21 Mar 89 18:05:49 PST (Tue)
   From: kend%mrloog.la.tek.com@RELAY.CS.NET

   JINX,

   Some general comments on your general comments:
   --------

	Some general comments on your proposal:

	2) I think it's premature to standardize on something like this for
	IEEE.  Proposals along these lines should certainly be considered for
	R5RS.

   On the contrary, we need to standardize library issues as soon as
   possible to keep divergence from preventing portability.  The IEEE
   standard is a good place for this.  I really would rather see only
   *language* issues in RnRS.  Most languages standardize too late--after
   implementations have significantly diverged--and there is hell to pay as
   each implementor tries to get *his* dialect as *the* standard (e.g.
   ATLAS).  Currently, we have a portable language, but not portable code.
   I believe that there is sufficient practical experience to have a
   standard interface to common functionality and that the IEEE standard
   needs such an interface to be viable. 

It seems that the situation that many of us feared is already coming to pass.
I see here a justification for why standardization should drive language design
rather than visa versa.  Let us remember that as difficult as it is to
standardize after peoples paths have diverged, it is even more difficult to
unstandardize a mistake.  I would oppose standardization of any feature that
has not been experimented with in its proposed form for standardization by the
Scheme community for at least 6 months.  DON'T RISK STANDARDIZATION OF
POTENTIAL BUGS.

	Comments on individual issues:


	4) RESET and FATAL-ERROR: I would propose a different, more powerful,
	procedure instead, on top of which both of these could easily be
	built.

	(ABORT-TO-NEAREST-REPL <thunk>)

	fetches a continuation created by the nearest repl (nearest in systems where
	there is more than one, like MIT Scheme, the top level one if there is
	only one) and executes <thunk> with this continuation.

	Thus

	(define (reset)
	  (abort-to-nearest-repl (lambda () unspecific)))

	(define (fatal-error message . irritants)
	  (abort-to-nearest-repl
	   (lambda ()
	     (for-each (lambda (unused-arg)
		    (display #\space)
		    (display obj))
		  (apply format #t message irritants))
	     (newline))))

   How is the "nearest repl" known to the runtime system?  How does a
   Scheme system recognize that a function is a (possibly user written)
   repl?  I don't have a problem with implementing RESET or FATAL-ERROR
   this way, but why standardize this function as a library routine?


	I have strong objections against having a procedure named FATAL-ERROR
	(or anything else with ERROR in it's name) which does not allow the
	option of fixing the bug and proceeding.

   Perhaps I'm confused.  You don't want a FATAL ERROR to abort a
   computation?  This might be a valuable behavior in a (possibly
   parallel) multi-tasking search situation.  What would be the
   difference between FATAL-ERROR and ERROR ?  The thing that I am trying
   to clean up here is the confusion over CERROR vs ERROR as to when an
   error is fatal and when recoverable.  `ERROR' is pretty common and
   typing RECOVERABLE-ERROR gets a bit tedious. 


	I'm not too attached to the name ABORT-TO-NEAREST-REPL.  The similar
	MIT Scheme procedure is called ABORT->NEAREST.

   I don't see this as a common usage in other Scheme implementations.
   Anyone? 

When someone is proposing new functionality, common usage should be irrelevant.
We should be trying to find the correct way of doing things, not the most
common way.  Common usage is a good argument as to why it is premature to
standardize this feature, not as to why a given functionality is more or less
desirable than another.  Lets here some substantive technical arguments for or
against different approaches.



	7) ALIAS: Why can't you just use (define <alias> <original>) ?

   This is hard to do with special forms.

	A different question is making your compiler generate reasonable code,
	but this should not be difficult.
	If you want to use it for special forms instead (like comment), I'd
	rather wait until we have some way of creating syntactic extensions.

   The reason for these bits of syntax is that we need to solve the
   portability problems now and we do not yet have syntactic extensions.
   Unless someone in Indiana moves fast, we will not have syntactic
   extensions in R4RS.  When we get syntactic extensions, these are easy
   to `define'.  I strongly suspect that the number of Scheme
   implementations is going to double every year or two for a while.  We
   need to be heading off the problems that will exist in 5 years unless
   fixed now. 

I feel VERY strongly that new syntactic forms of this sort should not be added
to Scheme.  Again, standardization seems to be driving language design, rather
than visa versa.  Lets put our effort into standardizing syntactic extensions
rather than into kludging around them.


	9) UNLESS and WHEN: I would wait for syntactic extensions.  I
	generally object to adding spurious special forms.

   We don't have syntactic extensions.  I see these in a lot of code.  I
   believe they are common usage.  Who else out there objects to these?
   Who else uses them?

I HATE the idea of adding unless and when to Scheme.  We already have enough
cruft in the form of do.  I use Scheme rather than CommonLisp because of its
elegance and simplicity.  The way we are going, I fear that pretty soon the two
will be indistinguishable.

   ----------
   Thank you very much for your input.

   -The Reader


					Morry Katz
					katz@polya.stanford.edu

Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 22 Mar 89 07:42:49 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
	id AA05578; Wed, 22 Mar 89 04:43:35 PDT
Date: Wed, 22 Mar 89 04:43:35 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903221243.AA05578@kestrel.arpa>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Tue, 21 Mar 89 23:31 EST <19890322043132.5.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Weird numeric predicates?

   Date: Tue, 21 Mar 89 23:31 EST
   From: Alan Bawden <Alan@AI.AI.MIT.EDU>

   Now, if you would like to argue with the given that the arithmetic
   primitives accept mixed exact and inexact arguments, we can do that.  You
   might even find that you can convince me.  But I don't want anyone to lose
   track of what I originally said because someone stigmatized it by using the
   word "DWIM" in its presence.  I was not proposing anything that could be
   described as DWIM, and in fact I was not proposing anything at all.  I was
   pointing out the consequences of two different implementations of the
   arithmetic comparison predicates.  Consequences, I might add, that most
   implementors seem to be unaware of.

My sincere apologies for the unclear prose.  Indeed, I should have
said I wasn't responding to your point directly but, as you say,
arguing with a given, one which had simply been brought to my
attention by your comments.  My only defense is that, while this idea
has been forming in my head for a while, this is the first time I've
attempted to express it.

However, the given I was arguing with is not exactly "that the
arithmetic primitives accept mixed exact and inexact arguments".  It
is that the arithmetic primitives are mode-generic: the mode in which
the operation is performed (exact or inexact) is dependent on the
exactness or inexactness of the arguments.  This is the characteristic
that I am attempting to stigmatize with the word "DWIM".

I am suggesting, as an alternative, that the primitives be bifurcated
into exact and inexact versions and that the mode in which the
operation is performed be dependent only on which primitive is
involved.  I am *not* suggesting that the primitives not accept mixed
exact and inexact arguments.

Thus, an exact primitive would coerce all arguments to be exact before
performing the operation, even if *all* of said arguments were
supplied in inexact form; conversely for inexact primitives.

Apologies again.  Is this making sense yet?

Scott

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Mar 89 23:34:10 EST
Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAR 89  23:38:28 EST
Date: Tue, 21 Mar 89 23:31 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Weird numeric predicates?
To: gyro@kestrel.arpa
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8903211120.AA28863@kestrel.arpa>
Message-ID: <19890322043132.5.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Tue, 21 Mar 89 03:20:09 PDT
    From: gyro@kestrel.arpa (Scott B. Layson)

       Date: Sun, 19 Mar 89 17:22 EST
       From: Alan Bawden <Alan@AI.AI.MIT.EDU>
       ....
       If instead comparison predicates coerce INEXACT->EXACT then consistently
       transitive answers will be obtained.

    I think that what this example really speaks to is the limitations of
    implicit arithmetic coercion.  It is really a form of DWIM.  (I am
    opposed to DWIM in any form -- some forms more than others.)

The first few times I read this paragraph I read it as accusing me of
advocating some form of DWIM.  I think I have now convinced myself that the
"it" in "It is really a form of DWIM" refers to the notion of coercing
between exact and inexact numbers in certain circumstances, and is not
directed at anything that I said.  Nevertheless, since the inflammatory
word "DWIM" has been used in close proximity to my message, I feel
compelled to restate the rather simple point that I was trying to make.

My entire point was that:

 Given that the current design for Scheme calls for the arithmetic
 primitives to accept exact or inexact arguments in any combination, then:
 
  1. If the comparison predicates compare exact numbers to inexact numbers
     by first coercing the exacts to inexacts, then the comparison
     predicates will not necessarily be transitive.  (Because
     EXACT->INEXACT is not an injection in the usual floating point
     implementation of inexact numbers.)
 
  2. If the comparison predicates compare exact numbers to inexact numbers
     by first coercing the inexacts to exacts, then the comparison
     predicates probably will be transitive.  (Because INEXACT->EXACT is an
     order preserving injection in the usual floating point implementation
     of inexact numbers.)

Now, if you would like to argue with the given that the arithmetic
primitives accept mixed exact and inexact arguments, we can do that.  You
might even find that you can convince me.  But I don't want anyone to lose
track of what I originally said because someone stigmatized it by using the
word "DWIM" in its presence.  I was not proposing anything that could be
described as DWIM, and in fact I was not proposing anything at all.  I was
pointing out the consequences of two different implementations of the
arithmetic comparison predicates.  Consequences, I might add, that most
implementors seem to be unaware of.


Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 21 Mar 89 22:47:14 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA09548@chamartin.AI.MIT.EDU>; Tue, 21 Mar 89 22:47:37 -0500
Date: Tue, 21 Mar 89 22:47:37 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903220347.AA09548@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 21 Mar 89 18:05:49 PST (Tue) <8903220205.AA22716@mrloog.LA.TEK.COM>
Subject: Portability (long)
Reply-To: jinx@zurich.ai.mit.edu


	 4) RESET and FATAL-ERROR: I would propose a different, more powerful,
	 procedure instead, on top of which both of these could easily be
	 built.

	 (ABORT-TO-NEAREST-REPL <thunk>)
	...

    How is the "nearest repl" known to the runtime system?  How does a
    Scheme system recognize that a function is a (possibly user written)
    repl?  I don't have a problem with implementing RESET or FATAL-ERROR
    this way, but why standardize this function as a library routine?

The idea is that the runtime system provides facilities for building
repls which interact with these abort procedures (there are many in
MIT Scheme), and can provide additional functionality.  While this
procedure is useful for writing things like RESET, it is useful in its
own right: interrupt characters cause invocations of such procedures
in MIT Scheme.  Dan Friedman needs something like
ABORT-TO-NEAREST-REPL for some of the stuff he does as well.

	 I have strong objections against having a procedure named FATAL-ERROR
	 (or anything else with ERROR in it's name) which does not allow the
	 option of fixing the bug and proceeding.

    Perhaps I'm confused.  You don't want a FATAL ERROR to abort a
    computation?  This might be a valuable behavior in a (possibly
    parallel) multi-tasking search situation.  What would be the
    difference between FATAL-ERROR and ERROR ?  The thing that I am trying
    to clean up here is the confusion over CERROR vs ERROR as to when an
    error is fatal and when recoverable.  `ERROR' is pretty common and
    typing RECOVERABLE-ERROR gets a bit tedious. 

I don't think such things as non-recoverable errors exist, thus I
would not like to have anything like FATAL-ERROR which by definition
implies non-recovery.

	 I'm not too attached to the name ABORT-TO-NEAREST-REPL.  The similar
	 MIT Scheme procedure is called ABORT->NEAREST.

    I don't see this as a common usage in other Scheme implementations.
    Anyone? 

I don't know what Dan Friedman is using, but, again, he's told me that
he would like to see it in some standard.

**********

	 5) ERROR must be a special form in order to get the environment of
	 the "call".  In MIT Scheme, the ERROR special form expands into
	 something like
	 (ERROR-PROCEDURE (the-environment) <message> . <irritants>)

    ERROR works just fine as a procedure in many systems (Chez Scheme, T,
    and MacScheme).  The fact that MIT Scheme has a non-standard way to
    access the environment makes it convenient for ERROR to be a special
    form in MIT Scheme.  I would really prefer that you propose an
    standard environment mechanism if you want to insist that ERROR must
    be a special form (or better yet, a standard error handling
    mechanism).  I really prefer procedures to special forms. 

I'm very confused.  As far as I know, all correct scheme
implementations must be properly tail recursive, and this is what forces
error to be a special form.  For example, in

(define (foo x y)
  (if (valid? x)
      (error "foo: Invalid x" x)
      (operate-on x y)))

if ERROR is an ordinary procedure, FOO tail recurses into it, which
means taht a debugger has no way of finding out what Y was.
Furthermore, a debugger can't even find out that error was called from FOO!
Either ERROR is mostly useless, or calls to ERROR must be treated
specially by the compiler, making these calls special forms by definition.

I only wrote what MIT Scheme does as an example of a possible
expansion for error.  Another possibility is to have

(error . args)

expand into

((error-procedure . args))

which guarantees that ERROR-PROCEDURE is not invoked in tail recursive
position.

The problem is not first class environments, but tail recursion!

    How much code would break if I change the wording to allow ERROR to be a
    procedure *or* a special form?

Yuck!

**********

	 6) TRACE and UNTRACE: Do you want identifiers or procedure objects?  

	 If you want procedure objects you are forcing implementations to make
	 them modifiable.

	 If you want identifiers you must make TRACE and UNTRACE special forms
	 so they can get the environment of the "call" and therefore alter the
	 correct bindings.

    These are procedures in MacScheme and PCScheme and special forms in
    Chez Scheme and T.  PCScheme, T, and MacScheme all require procedure
    objects rather than procedure names.  I will change the wording to
    indicate this and allow TRACE and UNTRACE to be either procedures or
    special forms.

As an aside, they are procedures in MIT Scheme, requiring procedures
as arguments.

The reason why TRACE and UNTRACE must be special forms if they require
identifiers has nothing to do with first class environments but
with tail recursion.  It is similar to the case of ERROR:

(let ((foo (lambda () <some code>)))
  (trace 'foo))

if TRACE is an ordinary procedure, it cannot see the binding of foo
because of lexical scoping, and cannot parse the stack to find it due
to tail recursion, which has forced the LET frame to be reclaimed.

You may reply that TRACE applies only to "top level bindings", but
such beasts do not exist in MIT Scheme or in T.

**********

	 7) ALIAS: Why can't you just use (define <alias> <original>) ?

    This is hard to do with special forms.

    ...

    The reason for these bits of syntax is that we need to solve the
    portability problems now and we do not yet have syntactic extensions.
    Unless someone in Indiana moves fast, we will not have syntactic
    extensions in R4RS.  When we get syntactic extensions, these are easy
    to `define'.  I strongly suspect that the number of Scheme
    implementations is going to double every year or two for a while.  We
    need to be heading off the problems that will exist in 5 years unless
    fixed now. 

Although I agree with the gist of your argument, I don't see how this
applies to ALIAS.  Either you have a special form in the first place
which you are providing an alias for, or you do not.  If you have it,
you can use the original.  If you don't, ALIAS won't solve your
problem: In order for ALIAS to be of any help in portability, you need
conditional compilation or conditional loading according to
implementation.  Whatever you use to discriminate according to
implementation, you can use to provide definitions of the "missing"
special forms using each implementation's syntactic extension
facilities.  As far as I know, all implementations have ways of
providing syntactic extensions.

**********

	 13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.

    So you want 3..258?  I think that silent masking of overflow would be
    pretty random. 

I meant that 8 bit bytes are pretty arbitrary.  It would be nice to be
able to read in (for example) 16 bit quantities, 32 bit quantities,
etc.  Furthermore, although rare, there are still machines around that
are not based on 8 bit bytes, and they may become popular again in the
future.  I would hate to see current hardware praxis getting into
the language.

**********

	 14) BOUND?: must be a special form, since it has no way of obtaining
	 the environment of the "call".

    I will update to be either procedure or special form.

The problem is similar to that of ERROR and TRACE.  Consider, for example

(let ((x 3))
  (if (bound? 'X)
      #t
      #f))

If BOUND? is an ordinary procedure, it has no access to the
environment of the call, which may not even exist by the time BOUND?
is entered.

Declaring that BOUND? acts only on "top level" identifiers does not
solve the problem either.

**********

	 15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
	 but not in internal definition position, and that makes them appear
	 strange.  I don't think that special forms like DEFINE-IF-<mumble> is
	 the way to conditionalize code, but this is a matter of taste.

    I don't see how these differ from non-conditional defines, which also
    appear strange.  I would be very happy to see a better proposal on
    conditional compilation.

The problem is clearest with DEFINE-IF-UNBOUND

(define (foo x)
  (define-if-unbound bar (+ x 3))
  (list x bar))

The contour where BAR is to be found depends on whether BAR is
available in the load-time environment, which is not visible at
compile time.  The code that the compiler must issue is not always
obvious, and it is always complicated.  Ordinary internal definitions
do not have such problems.  Would you consider LETREC-IF-UNBOUND?

Top level definitions do not present this problem if the compiler
treats references to such variables the same way that it treats
references to "globally" free variables, and are therefore handled by
the linker.

DEFINE-IF-IMPLEMENTATION has a similar problem in the presence of
separate compilation.

In general, as appealing as DEFINE-IF-<mumble> appears, I don't think
it is the way to achieve portability.

The way we tend to do that sort of thing around here is as follows:

Each program has two additional files, a compilation file, and a
loading file (they are often merged into one, but conceptually there
are two).  These files contain ordinary code which test the
implementation, query the user, etc, and then conditionally compile or
load the appropriate files.

For example, consider a hypothetical system consisting of three common
files (file1, file2, and file3), and for each implementation there is
an additional file with the implementation dependencies (including
syntactic extensions).  The compilation file would contain something like

(case (car (implementation-information))
  (("Implementation1")
   (compile-file "implementation1")
   (load-file "implementation1")) ; To provide syntactic extensions
  (("Implementation2")
   (compile-file "implementation2")
   (load-file "implementation2"))
  ...
  (else
   (error "Unknown implementation -- please port")))

(compile-file "file1")
(compile-file "file2")
(compile-file "file3")

The loading file would have similar code which would load the
appropriate parts of the system.

Although this mechanism is cumbersome for small programs, it works
very well for relatively large systems, and avoids rats' nests of
unreadable conditionally compiled code.

**********

	 17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.

    PCScheme has an AUTOLOAD-FROM-FILE procedure.  I will have the definition
    allow either a procedure or a special form.

Same problem as TRACE, BOUND?, etc.  I assume that in PCScheme it
always loads into the "global" environment.

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 21 Mar 89 21:24:34 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa13380; 21 Mar 89 21:19 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa28590; 21 Mar 89 21:12 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA10384; Tue, 21 Mar 89 18:05:27 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA03847; Tue, 21 Mar 89 18:04:16 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA22716; Tue, 21 Mar 89 18:05:51 pst
Message-Id: <8903220205.AA22716@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, 
    scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: Re: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
In-Reply-To: Your message of Sat, 18 Mar 89 07:55:29 -0500.
	     <8903181255.AA06322@chamartin.AI.MIT.EDU>
Date: 21 Mar 89 18:05:49 PST (Tue)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

JINX,

Some general comments on your general comments:
--------

     Some general comments on your proposal:
     
     1) We certainly need most of the functionality you have suggested.

I am happy that someone else thinks so.
     
     2) I think it's premature to standardize on something like this for
     IEEE.  Proposals along these lines should certainly be considered for
     R5RS.

On the contrary, we need to standardize library issues as soon as
possible to keep divergence from preventing portability.  The IEEE
standard is a good place for this.  I really would rather see only
*language* issues in RnRS.  Most languages standardize too late--after
implementations have significantly diverged--and there is hell to pay as
each implementor tries to get *his* dialect as *the* standard (e.g.
ATLAS).  Currently, we have a portable language, but not portable code.
I believe that there is sufficient practical experience to have a
standard interface to common functionality and that the IEEE standard
needs such an interface to be viable. 

    
     Comments on individual issues:
     
     1) IMPLEMENTATION-INFORMATION:  I'd much rather see strings returned.
     They are unlikely to be used often, so the extra time spent in the
     comparison should not be important.  The analogous MIT Scheme
     procedure returns a vector of strings and numbers.

A vector is fine by me.  Strings and exact integers are fine by me.  Anyone?
     

     Why is SCHEME-IMPLEMENTATION needed, given IMPLEMENTATION-INFORMATION?

I am happy to flush this.

     
     2) FORMAT: I assume you mean the current OUTPUT port when <port> is #t,
     rather than the current INPUT port.  I don't mind FORMAT, but I think
     that Chris Hanson has some objections to it, which is why MIT Scheme
     has flip-flopped between having it and not.

Yes, I do mean OUTPUT port (I am sure typo's abound).  Given string
ports, FORMAT is easy to implement and very useful.  Chris?

     
     3) PRETTY-PRINT: I would like to extend it in the following way: If
     <sexp> is a procedure object rather than a Sexp, it's source code (or
     suitable substitute if compiled and source is not available) is
     printed instead.

Fine.

     
     4) RESET and FATAL-ERROR: I would propose a different, more powerful,
     procedure instead, on top of which both of these could easily be
     built.
     
     (ABORT-TO-NEAREST-REPL <thunk>)
     
     fetches a continuation created by the nearest repl (nearest in systems where
     there is more than one, like MIT Scheme, the top level one if there is
     only one) and executes <thunk> with this continuation.
     
     Thus
     
     (define (reset)
       (abort-to-nearest-repl (lambda () unspecific)))
     
     (define (fatal-error message . irritants)
       (abort-to-nearest-repl
        (lambda ()
          (for-each (lambda (unused-arg)
     		 (display #\space)
     		 (display obj))
     	       (apply format #t message irritants))
          (newline))))

How is the "nearest repl" known to the runtime system?  How does a
Scheme system recognize that a function is a (possibly user written)
repl?  I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?

     
     I have strong objections against having a procedure named FATAL-ERROR
     (or anything else with ERROR in it's name) which does not allow the
     option of fixing the bug and proceeding.
     
Perhaps I'm confused.  You don't want a FATAL ERROR to abort a
computation?  This might be a valuable behavior in a (possibly
parallel) multi-tasking search situation.  What would be the
difference between FATAL-ERROR and ERROR ?  The thing that I am trying
to clean up here is the confusion over CERROR vs ERROR as to when an
error is fatal and when recoverable.  `ERROR' is pretty common and
typing RECOVERABLE-ERROR gets a bit tedious. 


     I'm not too attached to the name ABORT-TO-NEAREST-REPL.  The similar
     MIT Scheme procedure is called ABORT->NEAREST.

I don't see this as a common usage in other Scheme implementations.
Anyone? 

     
     5) ERROR must be a special form in order to get the environment of
     the "call".  In MIT Scheme, the ERROR special form expands into
     something like
     (ERROR-PROCEDURE (the-environment) <message> . <irritants>)

ERROR works just fine as a procedure in many systems (Chez Scheme, T,
and MacScheme).  The fact that MIT Scheme has a non-standard way to
access the environment makes it convenient for ERROR to be a special
form in MIT Scheme.  I would really prefer that you propose an
standard environment mechanism if you want to insist that ERROR must
be a special form (or better yet, a standard error handling
mechanism).  I really prefer procedures to special forms. 

How much code would break if I change the wording to allow ERROR to be a
procedure *or* a special form?

     
     6) TRACE and UNTRACE: Do you want identifiers or procedure objects?  
     
     If you want procedure objects you are forcing implementations to make
     them modifiable.
     
     If you want identifiers you must make TRACE and UNTRACE special forms
     so they can get the environment of the "call" and therefore alter the
     correct bindings.
     
These are procedures in MacScheme and PCScheme and special forms in
Chez Scheme and T.  PCScheme, T, and MacScheme all require procedure
objects rather than procedure names.  I will change the wording to
indicate this and allow TRACE and UNTRACE to be either procedures or
special forms.


     7) ALIAS: Why can't you just use (define <alias> <original>) ?
     
This is hard to do with special forms.

     A different question is making your compiler generate reasonable code,
     but this should not be difficult.
     If you want to use it for special forms instead (like comment), I'd
     rather wait until we have some way of creating syntactic extensions.
     
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
Unless someone in Indiana moves fast, we will not have syntactic
extensions in R4RS.  When we get syntactic extensions, these are easy
to `define'.  I strongly suspect that the number of Scheme
implementations is going to double every year or two for a while.  We
need to be heading off the problems that will exist in 5 years unless
fixed now. 


     8) COMMENT: I think you want to divorce the issues of reading and
     ignoring a form.  Maybe it's just a bug in your specification, but I'm
     not sure why you involve the reader at all.

I will elide the reference to READ.

     
     9) UNLESS and WHEN: I would wait for syntactic extensions.  I
     generally object to adding spurious special forms.
     
We don't have syntactic extensions.  I see these in a lot of code.  I
believe they are common usage.  Who else out there objects to these?
Who else uses them?


     10) COMMENT-WHEN: Does this imply read time or syntax time evaluation?
     Again, I'd wait for macros.

I was thinking of Chez Scheme's EVAL-WHEN when I wrote this (but we
don't have EVAL!).  Perhaps I should withdraw it and use Kent's
definition instead.  Kent?

     
     11) THE-CURRENT-DATE and THE-CURRENT-TIME: I assume you mean exact
     integers for fixnums.

Yes.

     
     12) string ports: I like them (and use them frequently), but I think
     we should bite the bullet and have constructors and selectors for ports:
     
     (MAKE-INPUT-PORT <char-peeker> <char-reader> <char-ready-predicate> <close>)
     (WITH-INPUT-PORT-COMPONENTS <input-port>
       (lambda (peek read ready? close)
         <actions>))
     
     (MAKE-OUTPUT-PORT <char-writer> <string-writer> <close>)
     (WITH-OUTPUT-PORT-COMPONENTS <output-port>
       (lambda (char-write string-write close)
         <actions>))
     
     String ports can easily be built on top of this, but other ports (to
     editor buffers, transcripting and tee'd ports, etc) can be built as well.

I will add this, but keep string ports as a common usage.

     
     13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.

So you want 3..258?  I think that silent masking of overflow would be
pretty random. 

     
     14) BOUND?: must be a special form, since it has no way of obtaining
     the environment of the "call".

I will update to be either procedure or special form.

     
     15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
     but not in internal definition position, and that makes them appear
     strange.  I don't think that special forms like DEFINE-IF-<mumble> is
     the way to conditionalize code, but this is a matter of taste.
    
I don't see how these differ from non-conditional defines, which also
appear strange.  I would be very happy to see a better proposal on
conditional compilation.

 
     I would also change the EQ?  test to STRING=? given my comments about
     IMPLEMENTATION-INFORMATION.

Yes, if this is the concensus.

     
     16) SORT and SORT!: You probably want (SORT <obj> <binary-predicate>).
     I don't know what predicate to use by default.

Yes, a <binary-predicate> is required.  There is no default.  Mea typola.

     
     17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.

PCScheme has an AUTOLOAD-FROM-FILE procedure.  I will have the definition
allow either a procedure or a special form.
     


----------
Thank you very much for your input.

-The Reader

Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 21 Mar 89 06:18:59 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
	id AA28863; Tue, 21 Mar 89 03:20:09 PDT
Date: Tue, 21 Mar 89 03:20:09 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903211120.AA28863@kestrel.arpa>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Sun, 19 Mar 89 17:22 EST <19890319222206.1.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Weird numeric predicates?

   Date: Sun, 19 Mar 89 17:22 EST
   From: Alan Bawden <Alan@AI.AI.MIT.EDU>

       Date: Fri, 17 Mar 89 11:26:05 -0500
       From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
       I haven't thought about it carefully, but it may not be reasonable
       (unless it is defined that way) to implement n-ary < and friends as
       the "AND accumulation" of binary <.  Comparisons between exact and
       inexact numbers should coerce the exact numbers to inexact, and this
       value may have to be used consistently afterwards.

   If <= is to behave transitively, even on inexact arguments, then you have
   to coerce inexact number to exact numbers in order to perform comparisons.
   (Or you must behave as if you did.)  To see why, consider the following
   three numbers:

     (DEFINE A (- (EXPT 10 38) 1))
     (DEFINE B 1E38)
     (DEFINE C (+ (EXPT 10 38) 1))

   Assuming your implementation has an exact representation for A and C
   (probably as a BIGNUM) and the inexact B is represented in a floating point
   format with less (probably far less!) that 38 digits of precision, then
   coercing either A or C to inexact will most likely return B.  If comparison
   predicates coerce EXACT->INEXACT, then the following will be true:

     (<= C B)	==>  #T
     (<= B A)	==>  #T
     (<= C A)	==>  #F

   Perhaps worse:

     (= C B)	==>  #T
     (= B A)	==>  #T
     (= C A)	==>  #F

   If instead comparison predicates coerce INEXACT->EXACT then consistently
   transitive answers will be obtained.

I think that what this example really speaks to is the limitations of
implicit arithmetic coercion.  It is really a form of DWIM.  (I am
opposed to DWIM in any form -- some forms more than others.)

To clarify what I am talking about, let me sketch an alternative set
of arithmetic primitives for a hypothetical version of Scheme.  (This
is not yet intended to be a formal proposal.)  Suppose there were two
sets of primitives, one for exact arithmetic, one for inexact; for
instance, exact equality might be EX= and inexact equality INEX=.
Both these primitives are required to accept both kinds of numbers as
arguments (this is *not* an efficiency hack to allow them to make
assumptions about the argument types); they then coerce both arguments
to exact or inexact, respectively, before making the comparison.

My claim is that distinguishing the two primitives makes sense because
they are really two different operations; INEX= really asks if the
arguments are equal within the floating-point precision of the
implementation.  Similar arguments hold for the other arithmetic
operations.

Implicit coercion is DWIMmy because it asks the system to choose one
of these two arguably different operations based on what the user
probably meant.  Especially in an untyped language where the
discrimination is made at runtime, this is an excellent way to produce
unmaintainable code.  (Suppose you have a program that does a lot of
arithmetic and, in debugging it, you find an inexact value where you
expected an exact one.  How are you going to find out where the
inexact operand was introduced?)

Notice that, given Alan's example values, both EX= and INEX= are
transitive:

     (EX= C B)	==>  #F
     (EX= B A)	==>  #F
     (EX= C A)	==>  #F

     (INEX= C B)  ==>  #T
     (INEX= B A)  ==>  #T
     (INEX= C A)  ==>  #T

Same for EX<= and INEX<=.

I am well aware that I am bucking Lisp tradition in making this
proposal.  However, there have been times when I was trying to do
numerics in Lisp when I wished I had a strongly-typed language, for
just this kind of reason -- a float would creep in somewhere and I
would have trouble finding where.  In (most?) strongly-typed languages
one still doesn't explicitly specify the mode in which the operation
is done separately from the types of the operands, but at least the
coercion rules apply at compile time.

(If you really want to make floating-point programs portable, how
'bout an optional third argument to *every* INEXop which is the number
of bits of precision (mantissa)?  (And even a fourth, which is the
number of bits of exponent?  (And then there's rounding...)))

To restate: I am basically proposing that the mode of each arithmetic
operation (exact or inexact; should there also be integer mode?) be
specified independently of the types of the operands.

-- Scott

Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 19 Mar 89 17:23:56 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182942; Sun 19-Mar-89 17:22:09 EST
Date: Sun, 19 Mar 89 17:22 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Weird numeric predicates?
To: jinx@ZURICH.AI.MIT.EDU, ziggy@VX.LCS.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8903171626.AA05893@chamartin.AI.MIT.EDU>
Message-ID: <19890319222206.1.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Fri, 17 Mar 89 11:26:05 -0500
    From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
    I haven't thought about it carefully, but it may not be reasonable
    (unless it is defined that way) to implement n-ary < and friends as
    the "AND accumulation" of binary <.  Comparisons between exact and
    inexact numbers should coerce the exact numbers to inexact, and this
    value may have to be used consistently afterwards.

If <= is to behave transitively, even on inexact arguments, then you have
to coerce inexact number to exact numbers in order to perform comparisons.
(Or you must behave as if you did.)  To see why, consider the following
three numbers:
  
  (DEFINE A (- (EXPT 10 38) 1))
  (DEFINE B 1E38)
  (DEFINE C (+ (EXPT 10 38) 1))

Assuming your implementation has an exact representation for A and C
(probably as a BIGNUM) and the inexact B is represented in a floating point
format with less (probably far less!) that 38 digits of precision, then
coercing either A or C to inexact will most likely return B.  If comparison
predicates coerce EXACT->INEXACT, then the following will be true:

  (<= C B)	==>  #T
  (<= B A)	==>  #T
  (<= C A)	==>  #F

Perhaps worse:

  (= C B)	==>  #T
  (= B A)	==>  #T
  (= C A)	==>  #F

If instead comparison predicates coerce INEXACT->EXACT then consistently
transitive answers will be obtained.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Mar 89 07:54:13 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA06322@chamartin.AI.MIT.EDU>; Sat, 18 Mar 89 07:55:29 -0500
Date: Sat, 18 Mar 89 07:55:29 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903181255.AA06322@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 17 Mar 89 17:07:16 PST (Fri) <8903180107.AA03798@mrloog.LA.TEK.COM>
Subject: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
Reply-To: jinx@zurich.ai.mit.edu

Some general comments on your proposal:

1) We certainly need most of the functionality you have suggested.

2) I think it's premature to standardize on something like this for
IEEE.  Proposals along these lines should certainly be considered for
R5RS.

Comments on individual issues:

1) IMPLEMENTATION-INFORMATION:  I'd much rather see strings returned.
They are unlikely to be used often, so the extra time spent in the
comparison should not be important.  The analogous MIT Scheme
procedure returns a vector of strings and numbers.

Why is SCHEME-IMPLEMENTATION needed, given IMPLEMENTATION-INFORMATION?

2) FORMAT: I assume you mean the current OUTPUT port when <port> is #t,
rather than the current INPUT port.  I don't mind FORMAT, but I think
that Chris Hanson has some objections to it, which is why MIT Scheme
has flip-flopped between having it and not.

3) PRETTY-PRINT: I would like to extend it in the following way: If
<sexp> is a procedure object rather than a Sexp, it's source code (or
suitable substitute if compiled and source is not available) is
printed instead.

4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.

(ABORT-TO-NEAREST-REPL <thunk>)

fetches a continuation created by the nearest repl (nearest in systems where
there is more than one, like MIT Scheme, the top level one if there is
only one) and executes <thunk> with this continuation.

Thus

(define (reset)
  (abort-to-nearest-repl (lambda () unspecific)))

(define (fatal-error message . irritants)
  (abort-to-nearest-repl
   (lambda ()
     (for-each (lambda (unused-arg)
		 (display #\space)
		 (display obj))
	       (apply format #t message irritants))
     (newline))))

I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.

I'm not too attached to the name ABORT-TO-NEAREST-REPL.  The similar
MIT Scheme procedure is called ABORT->NEAREST.

5) ERROR must be a special form in order to get the environment of
the "call".  In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)

6) TRACE and UNTRACE: Do you want identifiers or procedure objects?  

If you want procedure objects you are forcing implementations to make
them modifiable.

If you want identifiers you must make TRACE and UNTRACE special forms
so they can get the environment of the "call" and therefore alter the
correct bindings.

7) ALIAS: Why can't you just use (define <alias> <original>) ?
A different question is making your compiler generate reasonable code,
but this should not be difficult.
If you want to use it for special forms instead (like comment), I'd
rather wait until we have some way of creating syntactic extensions.

8) COMMENT: I think you want to divorce the issues of reading and
ignoring a form.  Maybe it's just a bug in your specification, but I'm
not sure why you involve the reader at all.

9) UNLESS and WHEN: I would wait for syntactic extensions.  I
generally object to adding spurious special forms.

10) COMMENT-WHEN: Does this imply read time or syntax time evaluation?
Again, I'd wait for macros.

11) THE-CURRENT-DATE and THE-CURRENT-TIME: I assume you mean exact
integers for fixnums.

12) string ports: I like them (and use them frequently), but I think
we should bite the bullet and have constructors and selectors for ports:

(MAKE-INPUT-PORT <char-peeker> <char-reader> <char-ready-predicate> <close>)
(WITH-INPUT-PORT-COMPONENTS <input-port>
  (lambda (peek read ready? close)
    <actions>))

(MAKE-OUTPUT-PORT <char-writer> <string-writer> <close>)
(WITH-OUTPUT-PORT-COMPONENTS <output-port>
  (lambda (char-write string-write close)
    <actions>))

String ports can easily be built on top of this, but other ports (to
editor buffers, transcripting and tee'd ports, etc) can be built as well.

13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.

14) BOUND?: must be a special form, since it has no way of obtaining
the environment of the "call".

15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
but not in internal definition position, and that makes them appear
strange.  I don't think that special forms like DEFINE-IF-<mumble> is
the way to conditionalize code, but this is a matter of taste.

I would also change the EQ?  test to STRING=? given my comments about
IMPLEMENTATION-INFORMATION.

16) SORT and SORT!: You probably want (SORT <obj> <binary-predicate>).
I don't know what predicate to use by default.

17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.

Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Mar 89 04:06:36 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
	id <AA05893@chamartin.AI.MIT.EDU>; Fri, 17 Mar 89 11:26:05 -0500
Date: Fri, 17 Mar 89 11:26:05 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903171626.AA05893@chamartin.AI.MIT.EDU>
To: ziggy@VX.LCS.MIT.EDU
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Fri, 10 Mar 89  12:49:35 EST <2814544175-9975825@RTS-8>
Subject:  Wired numeric predicates?
Reply-To: jinx@zurich.ai.mit.edu

    I understand your rationale for not wanting numeric predicates to be special
    forms.  The reason I brought it up was that I am a Teaching Assistant in an
    undergrad course this term that uses Scheme.  A student raised the issue since
    it seems natural to think of (< x1 x2 x3...) as being the AND of each of the
    individual two-step comparisons.  The resemblence between this and the AND
    form were sufficiently strong that the student conveniently ignored the fact
    that we explicitly describe < as being a *procedure* and not as a *special
    form*...  I guess people naturally don't look carefully at things that they
    consider ``intuitively obvious''. (Actually, MIT Scheme also defines AND to be
    a procedure, but we had blown this at the time... the student wanted to know
    about MACScheme).

Minor comments:

6.001 Scheme has AND as a procedure because SICP used it that way.
AND is a special form in MIT Scheme, of which 6.001 is not a subset.

I haven't thought about it carefully, but it may not be reasonable
(unless it is defined that way) to implement n-ary < and friends as
the "AND accumulation" of binary <.  Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact, and this
value may have to be used consistently afterwards.

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 17 Mar 89 23:54:36 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag05233; 17 Mar 89 23:36 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa04229; 17 Mar 89 23:28 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA26208; Fri, 17 Mar 89 17:07:12 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA20108; Fri, 17 Mar 89 17:05:52 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
	id AA03798; Fri, 17 Mar 89 17:07:22 pst
Message-Id: <8903180107.AA03798@mrloog.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
Date: 17 Mar 89 17:07:16 PST (Fri)
From: kend%mrloog.la.tek.com@RELAY.CS.NET

; FILE:		Portability-Proposal
; IMPLEMENTS:	Proposal for suggested library function interface
; AUTHOR:	Ken Dickey
; DATE:		1989 February 19
; LAST UPDATED: 1989 March 17
; HISTORY:
; STATUS:	DRAFT (#1)


PREFACE:

The number of Scheme implementations is rapidly growing.  This
document is an attempt to deal with portability issues so that
applications can be made source-portable with a single compatability
file across differing Scheme implementations.  A recommended standard
library interface is included, with the recognition that not all
functions make sense for all implementations (e.g. the THE-CURRENT-TIME
function for embedded applications lacking real-time clock support). 

The main portability issues addressed here deal with the ability to
programatically query an implementation and fill in the gaps between
the implementation supplied library and an application.  Specifically,
to provide baseline functionality, specialize machine independent to
implementation specific functions, and allow implementation-dependent
optimizations.  

Baseline functionality consists of augmenting an implementation's
library to include all functions required by an application.  For
example, if hash-tables are not provided by the implementation, they
may be provided by the application.  However, hash-tables provided by
an implementation may be significantly more efficient than those an
application might provide and are to be preferred if offered.

Specializing machine independent to implementation specific functions
requires mapping an application defined interface to idiosyncratic
implementation, operating system, or hardware features.  For example,
an application may typically map conventionalized to idiosyncratic
line drawing functions. 

Implementation dependent optimizations can have a major impact on
application performance.  Writing portable applications of significant
size requires allowing the use of some optimizations where they are
available.  A typical example is allowing a compiled implementation to
consider certain definitions as constant so that folding or code
inlining optimizations may be performed.


===========================================================================

=======================
IMPLEMENTATION QUERIES:
=======================

========
FUNCTION: (IMPLEMENTATION-INFORMATION) 
========

RETURNS: A proper list of the form:

  (<name> <version> <MACHINE> <CPU> <OS> <FS> . <supports>)

Each object returned is a symbol or #f.  It is recommended that
symbols be in mixed case (as if created with STRING->SYMBOL). 

EXAMPLE: (implementation-information) -->
(BogusScheme 1.0 Valhalla-9000 68080 GNUnix GNUfs Complex Reals X21)

NOTES: Case is used for readability and uniqueness.  <Supports>
options can be checked with memq. <Version> can be parsed after
SYMBOL->STRING conversion (see string ports). 


========
FUNCTION: (SCHEME-IMPLEMENTATION)
========

RETURNS: a proper list of the form (<name> <version>), where <name> and
<version> are symbols.



===========================================================================
================
FORMATTED OUTPUT
================

========
FUNCTION: (FORMAT <port> <format-string> . <args>)
========

RESULT: returns unconsumed <args> or a string; has side effect of
printing according to <format-string>.  If <port> is #t the output is
to the current input port.  If <port> is #f, a formatted string is
returned as the result of the call.  Otherwise <port> must be an
output port.  <format-string> must be a string.  Characters are output
as if the string were output by the DISPLAY function with the
exception of those prefixed by a tilde (~) as follows:

~a  any: display the object (as for humans).
~s  slashified: write the object (as for parsers).
~d  decimal: the integer argument is output in decimal format.
~x  hexadecimal: the integer argument is output in hexadecimal format.
~o  octal: the integer argument is output in octal format.
~b  binary: the integer argument is output in binary format.
~p  plural: if the argument is greater than 1, a lower case 's' is printed.
~c  character: the next argument is displayed as a character.
~_  space: output a space character.
~%  newline: output a newline character.
~&  freshline: unless at the beginning of a line, same as ~%, else ignored.
~|  page seperator: output a page seperator.
~~  tilde: output a tilde.
~t  tab: output a tab charcter.
~g  glorify: pretty print the argument (typically an s-expression).
~?  indirection: take the next argument as a format string and consume
    further arguments as appropriate, then continue to process the current
    format string.

========
FUNCTION: (PRETTY-PRINT <sexp> . <port>)
          (PRETTY-PRINT <sexp> <port> . <width>)
========

RETURNS: Unspecified.  Side effect it to output the <sexp> in an
implementation dependent manner. 


===========================================================================
==============
ERROR HANDLING
==============

========
FUNCTION: (RESET)
========

RETURNS: No, it never returns.  In implementations which interact with
the user via a top-level repl (read eval print loop), this function
has the effect of returning to the top-level repl.  Other actions are
implementation dependent.


========
FUNCTION: (FATAL-ERROR <message> . <irritants>)
========

RETURNS: No, it never returns.  This function typically has the side
effect of FORMATting the <message>--which should be a format string
to the current output port.  Any <irritants> unconsumed by format are
DISPLAYed to current output port.  This is a fatal error.  In
implementations which interact with the user via a top-level repl, a
RESET is performed.  Other actions are implementation dependent, but
may include process termination. 

EXAMPLE:
> (+ 2 (fatal-error "this is an ~a with extra arguments" 'error 1 2 3))
= this is an ERROR with extra arguments 1 2 3
>

========
FUNCTION: (ERROR <message> . <irritants>)
========

RETURNS: Implementation dependent.  This behaves as FATAL-ERROR as far as
output of the <message> and <irritants>, but is possably continuable in
implementations providing an interactive inspector or other error
handling. 


========
FUNCTION: (INSPECT . <obj>)
========

RETURNS: It depends.  If <obj> is specified, it is the default return
value, else #f is the default.  What is actually returned is usually
up to user discretion.  This command invokes an interactive inspector
in the invoking enviromnent.  If an <obj> argument is present, it is
the initial object of the inspection. 


========
FUNCTION: (TRACE . <identifiers>)
========

RETURNS: Unspecified.  Identifiers must have values.  If an identifier
designates a function, that function is traced on entry and exit.


========
FUNCTION: (UNTRACE . <identifiers>)
========

RETURNS: Unspecified.  Removes the trace side effect on traced
identifiers.  With no arguments, untraces all traced identifiers.



===========================================================================
======
SYNTAX
======

============
SPECIAL FORM: (ALIAS <alias> <original>)
============

RETURNS: Unspecified.  Has the side effect of creating an alias for
the original when it occurs in the call position.  Both arguments must
be identifiers.  <Original> must exist at time of call.

EXAMPLEs: (alias herald comment)  (alias debug inspect)


============
SPECIAL FORM: (COMMENT . <any>)
============

RESULT: The comment syntax is read as if by READ and discarded.  The
effect is interpreted or compiled as whitespace.


============
SPECIAL FORM: (UNLESS <test> <expressions>...)
============

RESULT: If <test> is #f, acts as (BEGIN <expressions>...), else
returns #t. 


============
SPECIAL FORM: (WHEN <test> <expressions>...)
============

RESULT: If <test> is #t, acts as (BEGIN <expressions>...), else
returns #f. 


============
SPECIAL FORM: (COMMENT-WHEN <test> <exp> . <exps>)
============

RESULT: If <test> is #f, then acts as COMMENT else acts as BEGIN (which
is flattened into the current contour).



===========================================================================
====
TIME
====

========
FUNCTION: (THE-CURRENT-DATE)
========

RETURNS: A list of 3 fixnums: (<year> <month> <day>) where <year> is
based on the Julian calendar and <month> <day> are based on 1.

EXAMPLE: (the-current-date) --> (2001 1 23)


========
FUNCTION: (THE-CURRENT-TIME)
========

RETURNS: A list of 3 fixnums: (<hour> <minute> <second>) in 24-hour format.

EXAMPLE: (the-current-time) --> (13 23 30)


========
FUNCTION: (RUNTIME)
========

RETURNS: An approximation to the number of microseconds the current
process has been running.


========
FUNCTION: (UPTIME)
========

RETURNS: An approximation to the number of seconds the since the
system was booted.


===========================================================================
============
STRING PORTS
============

========
FUNCTION: (OPEN-INPUT-STRING <string>)
========

RETURNS: An input port.

NOTES: Useful to READ.


========
FUNCTION: (GET-OUTPUT-STRING <string-port>)
========

RETURNS: A string.  <String-port> must have been created by
OPEN-OUTPUT-STRING. Has the logical side effect of reseting the
string-port to the empty string.

========
FUNCTION: (OPEN-OUTPUT-STRING)
========

RETURNS: An output port.

NOTES: Useful to WRITE and PORT->STRING.


========
FUNCTION: (STRING-PORT? <port>)
========

RETURNS: #t if <port> is a string port, else #f.



===========================================================================
==========
BINARY I/O
==========

========
FUNCTION: (WRITE-BYTE <value> . <port>)
========

RETURNS: Unspecified.  Side effect is to output <value>, which must be
a number in the range 0..255, in machine (binary) format.


========
FUNCTION: (READ-BYTE <value> . <port>)
========

RETURNS: The EOF-object or a fixnum in the range 0..255.



===========================================================================
============
BYTE VECTORS
============

========
FUNCTION: (BYTE-VECTOR <value>...)
========

RETURNS: A byte-vector of the same length as the number of values
supplied.  Each value must be a number in the range 0..255.


========
FUNCTION: (BYTE-VECTOR-REF <bv> <index>)
========


========
FUNCTION: (BYTE-VECTOR-SET! <bv> <index> <new-value>)
========


========
FUNCTION: (BYTE-VECTOR->STRING <bv>)
========


========
FUNCTION: (STRING->BYTE-VECTOR <string>)
========


========
FUNCTION: (BYTE-VECTOR->LIST <bv>)
========


========
FUNCTION: (LIST->BYTE-VECTOR <string>)
========


========
FUNCTION: (BYTE-VECTOR? <obj>)
========

RETURNS: #t if <obj> is a byte-vector, else #f.



===========================================================================
===========
DEFINITIONS
===========

========
FUNCTION: (BOUND? <identifier>)
========

RETURNS: #t if <identifier> is bound in the environment of the call,
else #f.


========
FUNCTION: (DEFINE-IF-UNBOUND <name> <exp>)
          (DEFINE-IF-UNBOUND (<name> <args>) <exp>)
========

NOTES: If <name> is unbound, the definition is as per DEFINE, else as
per COMMENT.


========
FUNCTION: (DEFINE-IF-IMPLEMENTATION <implementation> <name> <exp>)
          (DEFINE-IF-IMPLEMENTATION <implementation> (<name> <args>) <exp>)
========

NOTES: If <implementation> is eq? to (CAR (IMPLEMENTATION-INFORMATION))
then definition is as per DEFINE, else as per COMMENT.


===========================================================================
==========
STRUCTURES
==========

============
SPECIAL-FORM: (DEFINE-STRUCTURE <structure-name> <field> ...)
============

RESULT: Defines a disjoint record type with a named set of fields.
The following are defined: 
  predicate 				<structure-name>?
  constructor				MAKE-<structure-name> 
  a setter for each field 		SET-<structure-name>-<field>!  
  and an accessor for each field 	<structure-name>-<field>
,
Fields may be initialized if of the form: (<field-name> <exp>), where
<exp> is evaluated once in the environment of the define-structure
form. Uninitialized fields default value is #f.

EXAMPLE: (define-structure quux bar (baz 20)) has the effect of
defining MAKE-QUUX, QUUX?, QUUX-BAR, SET-QUUX-BAR!, QUUX-BAZ,
and SET-QUUX-BAZ!.
  (quux-bar (make-quux)) --> #f
  (quux-baz (make-quux)) --> 20


===========================================================================
====
MISC:
====

========
FUNCTION: (RANDOM <limit> . <seed>)
========

RETURNS: A number between zero (inclusive) and <limit> (exclusive).
The argument(s) must be numbers.  An approximation to a uniform
distribution is used.  The <seed> argument is used to be able to
repeat the same pseudo-random sequence.


========
FUNCTION: (SORT <obj>) 
========

RETURNS: A newly allocated object of the same type as <obj> with
<obj>'s elements sorted.  <Obj> must be a list, vector, string, or
byte-vector.


========
FUNCTION: (SORT! <obj>) 
========

RETURNS: Original <obj> with elements sorted.  <Obj> must be a list,
vector, string, or byte-vector. 


========
FUNCTION: (SUSPEND <filespec>) 
========

RETURNS: Error if suspension was unsuccessful, else implementation
dependent (typically returns to native operating system).  Saves an
approximation to the current state of computation in an implementation
dependent manner to a file denoted by <filespec> which can later be
invoked in an implementation dependent manner.  Note that some system
state (such as the state of open files) may not be restorable.


========
FUNCTION: (AUTOLOAD <name-or-namelist> <filespec>)
========

RETURNS: Unspecified.  Side effect is delayed definition in current
scope.  When a function is initially referenced, it is automagically
loaded before being invoked. <name-or-namelist> must be an identifier
or a list of identifiers which are presumed to denote functions defined
in file referenced by <filespec>.
      


===========================================================================
###########################################################################
===========================================================================
	End Of Interface
===========================================================================
###########################################################################
===========================================================================


===========================================================================
=====
NOTES:
=====

IMPLEMENTATION-INFORMATION returns mixed case symbols--I thought this
would get your attention! 

FORMAT returns unused arguments: this makes format somewhat easier to
write and allows FATAL-ERROR to be defined without a second format
function:
    (define (FATAL-ERROR <format-string> . <args>)
        (let ( (unused-args 
                 (apply format `(#t "~&~?" ,<format-string> ,@<args>))
               )
             )     
          (unless (null? unused-args) 
              (for-each (lambda (arg) (display #\space) (display arg))
                        unused-args)
          )
          (display #\newline)
          (reset) 
    )   )

COMMENT-WHEN: does the job of eval-when, compile-when, etc.  I would
like to avoid the eval-time vs compile-time question for now.  I
definately feel the need for conditional compilation.  What do you
think? 

WHEN, UNLESS: I see these in a lot of code.  I use them.  How about
other very common patterns? 

BOUND?: I know, I know.  But how are we to write DEFINE-IF-UNBOUND
unless we can test somewhere?  Do we keep this as magic? 

DEFINE-IF-<condition>: If we accept COMMENT-WHEN and BOUND?, are these
needed?

SORT: Assumed to do a typed dispatch to LIST-SORT, VECTOR-SORT, etc.  (at
least until we have an object system interface such as Amos provides).

Raw and Cooked I/O {QUUX-NO-HANG}: I have not proposed anything here
because this is a tasking issue.  Either you use READ-CHAR and
CHAR-READY? as specified by R3RS {cooked} or you are dealing with
buffers and interrupts and you have to deal with {raw} rubout
characters yourself.  Binary i/o allows us to implement buffers if we
face the tasking questions {see Interrupts/Handlers, below}.  Once we
have portable, buffered i/o we can write portable editors--just like
real languages. 



===========================================================================
===========
UNADDRESSED: Here are some further topics that should be addressed.
===========  You can add more.  Since I did such a bad job above,
you should be able to come up with a better proposal on one or more of
these.


Interrupts/Handlers {We need these as abstract services.
		    I would be real pleased if Will Clinger and Kent
		    Dybvig to got together to propose something (hint)}

Storage Recycling (GC), pre- and post-gc hooks.

Tables, Hashing, [Populations]

File Seeking {The Pascal Standard has a reasonable file specification}

Foreign Function Interface -- {Some say not a real language without it!}

Errorset, Programatic error handling.

File-System Objects and Structured File-Names (as in T or CL)

Numeric Precision & Numerics in general

Syntactic Extensions



===========================================================================
================
GENERAL COMMENTS
================

R3RS is a good job of language specification.  But a language without
a reasonably large library of standard functions will not be taken
seriously.  I consider the above to be just short of barely adequate.
My hope is to come to a concensus in time to get a reasonable library
appendix in the IEEE Scheme Standard.  I could use some help.

Thanks in advance,
-Ken				kend@mrloog.LA.TEK.COM
==================================E=O=F====================================

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Mar 89 13:56:46 EST
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Mar 89 13:57-EST
Message-Id: <2815153014-7973682@RTS-8>
Sender: ziggy@RTS-8
Date: Fri, 17 Mar 89  13:56:54 EST
From: "Michael R. Blair" <ziggy@vx.lcs.mit.edu>
To: jinx@chamartin.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Exactness contagion and wired numeric predicates

Not to belabor a belabored point, but this exactness issue you raised seems
interesting in its own right...

       I haven't thought about it carefully, but it may not be reasonable
       (unless it is defined that way) to implement n-ary < and friends as
       the "AND accumulation" of binary <.  Comparisons between exact and
       inexact numbers should coerce the exact numbers to inexact, and this
       value may have to be used consistently afterwards.

Yow!  I guess if we don't coerce all of them to inexact if even one of them is
inexact then we could reveal the evaluation order of the sequence.  To point:
verifying monotonic increasing can be done by verifying monotonic decreasing
in the other direction.  If you go left to right where the left is inexact and
the right is exact [Fig.0] then you coerce the exact to an inexact for the
comparison.

  Fig.0:   (< inexact exact exact)

The question is, do you use this inexact coerced value for the comparison with
the number to the right or not?  If so, then you will not be consistent with
the right to left comparison (assuming this right to left likewise uses the
coerced value for the continued ``AND accumulation'').

 However, in the re-write rule that I sketched in the original message, I
(unwittingly) arranged to NOT use the coerced value for the subsequent
comparison.  The re-write rule looked like...

 (let iter (lambda (current-expr rest-exprs)
    ...
    (let ((next-expr (car rest-exprs)))
      (and (< current-expr next-expr)		; Maybe Coerce next-expr here
           (iter next-expr (cdr rest-exprs))))	; But that does not mutate it!
    ...))

 In fact, I don't see a reasonable way to ``get a handle on'' the coerced
value (used internally for the <) so that you could propagate this
`inexactness contagion'.  If we were to define the < et al.  by the above
re-writing then the issue is mute.  (Granted, the above rule specifies
left-to-right but we could remedy this by writing:

 (let ((list-of-comparees (reverse-or-not comparees)))
   ...<rule>...)

...where reverse-or-not non-deterministicall reverses a list or doesn't. This
is no more (or less) offesive than using PERMUTE in the semantics to
intentionally ambiguate the evaluation order of argument lists.

Anyway, I thought this amusing.					Cheers,
								~Ziggy

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 10 Mar 89 18:25:02 EST
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 10 Mar 89 12:50-EST
Message-Id: <2814544175-9975825@RTS-8>
Sender: ziggy@RTS-8
Date: Fri, 10 Mar 89  12:49:35 EST
From: "Michael R. Blair" <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Re:  Wired numeric predicates?

I tried replying directly to Will Clinger but I cannot seem to successfully
route replies to him, so I forwarded this to the list. Perhaps it is of
general interest anyway. Thanks for your reply, Will.

----------------------------

Yes.  I know the R^3 Manual is not ambiguous on the point that < et al.  are
procedures and not special forms.  I'm sorry if I sounded alarmist about this.
I just wondered if the non-ambiguity was intentional or desireable.

I understand your rationale for not wanting numeric predicates to be special
forms.  The reason I brought it up was that I am a Teaching Assistant in an
undergrad course this term that uses Scheme.  A student raised the issue since
it seems natural to think of (< x1 x2 x3...) as being the AND of each of the
individual two-step comparisons.  The resemblence between this and the AND
form were sufficiently strong that the student conveniently ignored the fact
that we explicitly describe < as being a *procedure* and not as a *special
form*...  I guess people naturally don't look carefully at things that they
consider ``intuitively obvious''. (Actually, MIT Scheme also defines AND to be
a procedure, but we had blown this at the time... the student wanted to know
about MACScheme).

I suspect this is a very common misconception among naive users, which
suggests to me that the language would have a more uniform interface to
the user if the numeric predicates were in fact special forms.

Again, I see the language designers view that we want as little special
syntax as necessary to reinforce that we use it only where it is REALLY
needed. However, this viewing angle produces a uniformity in the language
_design_ which does not result in as uniform a _language interface_.

I guess this is just a matter of emphasis/taste. I really have not strong
opinions on this... was just curious.
							~Ziggy

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  5 Mar 89 16:38:04 EST
Received: from RTS-8.LCS.MIT.EDU by LCS.MIT.EDU via Chaosnet; 5 Mar 89 16:37-EST
Message-Id: <2814125888-4779862@RTS-8>
Sender: ziggy@RTS-8
Date: Sun, 5 Mar 89  16:38:08 EST
From: "Michael R. Blair" <ziggy@vx.lcs.mit.edu>
To: rrrs-authors@mc
Subject: Wired numeric predicates?

 The R^3 Report mentions multiple argument variations on the numeric
predicates (like =, <, et al) which test (resp) numeric equality,
monotonically increasing numeric sequence, ...

 May some implementations implement these as left-to-right special forms
(derived expressions) where once a #F result is established the remaining
terms are not evaluated?  If so, the manual should be careful not to call
these ``procedures'', or at least to mention that some implementations allow
them to not be procedures.

 I ask because it seemed natural to think of (say) < as being:

 (< <x1> <x2> <x3>...) = (let* ((temp1 <x1>)	; Preserve L->R eval while
                                (temp2 <x2>))   ; avoiding evaling <x2> twice
                           (and (< temp1 temp2) (< temp2 <x3>...)))

 For example, (= 1 2 (diverge)) ==> #F


 Or maybe different names should be used for the wired versions? Like putting
a `?' in there names (or maybe better for wired predicates to NOT have `?'s
and non-wired ones TO have them).
								Regards,
								~Ziggy

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 20 Feb 89 17:33:36 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag01534; 20 Feb 89 17:01 EST
Received: from cs.brandeis.edu by RELAY.CS.NET id af27950; 20 Feb 89 16:57 EST
Received: from coconut (peanut.cs.brandeis.edu) by cs.brandeis.edu (13.1/6.0.GT)
	id AA09594; Mon, 20 Feb 89 09:15:08 est
Posted-Date: Mon, 20 Feb 89 09:18:32 est
Received: by coconut (13.1/4.7)
	id AA16549; Mon, 20 Feb 89 09:18:32 est
Date: Mon, 20 Feb 89 09:18:32 est
From: Jim Miller <jmiller%coconut%cs.brandeis.edu@RELAY.CS.NET>
Message-Id: <8902201418.AA16549@coconut>
To: chaynes%iuvax.cs.indiana.edu%coconut%cs.brandeis.edu@RELAY.CS.NET
Cc: rrrs-authors%mc.lcs.mit.edu%relay.cs.net%coconut%cs.brandeis.edu@RELAY.CS.NET
In-Reply-To: Chris Haynes's message of Sat, 18 Feb 89 21:01:37 -0500 <8902190205.AA08909@ZURICH.AI.MIT.EDU>
Subject: ... should be a peculiar identifier
Reply-To: JMiller%cs.Brandeis.edu@RELAY.CS.NET

I heartily endorse your suggestion, but for a slightly different
(selfish) reason.  I often distribute code for problem sets to
students and I like to put these same ellises ("...") into that code
to indicate the parts that they should fill in.  I, too, have been
bitten by the fact that it's not an identifier since the code can't
even be loaded (let alone executed) when they are present.

--Jim

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 20 Feb 89 15:37:44 EST
Received: by void.ai.mit.edu (5.59/1.5)
	id AA02864; Mon, 20 Feb 89 15:43:30 EST
Date: Mon, 20 Feb 89 15:43:30 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902202043.AA02864@void.ai.mit.edu>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 20 Feb 89 11:38:46 PST <890220-113900-10189@Xerox>
Subject: ... should be a peculiar identifier
Reply-To: jar@zurich.ai.mit.edu

   Date: Mon, 20 Feb 89 11:38:46 PST
   From: Pavel.pa@Xerox.COM

   I strongly support this proposal, though I might go further and allow ``.''
   as a normal constituent character, disallowing only the name ``.'' for
   symbols.

In effect, this is already the case, since . + - are "special
subsequents" according to the grammar in section 7.1.1 of the
Revised^3 Report.  The grammar thus allows identifiers like A..B,
SET-CAR!, and so on.  The text in section 2.1 is in error in not
describing this possibility.  In my opinion it is section 7.1.1 that
reflects current practice and the consensus of the authors, not
section 2.1.  Sorry for getting it wrong.  I would like to direct the
editors of the Revised^4 Report and the IEEE Draft Standard to fix
section 2.1.  I think it would suffice to add + - . to the list of
extended alphabetic characters.

My opinion on the "..." question is that I would like to see
incompatibilities with Common Lisp, as well as differences between the
^3 and ^4 reports, minimized, and thus leave "..." as it stands, namely
not generated by the grammar.  I suggest the alternative "---" for use
in pattern languages.  But I may have used up my opinion quota on the
last report.

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 20 Feb 89 14:42:50 EST
Received: from Semillon.ms by ArpaGateway.ms ; 20 FEB 89 11:39:00 PST
Date: Mon, 20 Feb 89 11:38:46 PST
From: Pavel.pa@Xerox.COM
Subject: Re: ... should be a peculiar identifier
In-reply-to: "chaynes@iuvax.cs.indiana.edu's message of Sat, 18 Feb 89
 21:01:37 -0500"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890220-113900-10189@Xerox>

I strongly support this proposal, though I might go further and allow ``.''
as a normal constituent character, disallowing only the name ``.'' for
symbols.

	Pavel

Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 20 Feb 89 14:23:36 EST
Received: by ZOHAR.AI.MIT.EDU; Mon, 20 Feb 89 14:26:32 est
Date: Mon, 20 Feb 89 14:26:32 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8902201926.AA04455@zohar>
To: chaynes@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Haynes's message of Sat, 18 Feb 89 21:01:37 -0500
Subject: ... should be a peculiar identifier

I strongly agree with this proposal.

I also believe that the peculiar identifiers list should be extensible
in this and in any other useful direction.  Users should be free to
pick identifiers so long as they do not conflict with other types.  It
is unnecessary (and unpleasant) for us to PREVENT any exotic features
from being developed that may need identifiers that CANNOT BE confused
with any other syntatic type.

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 20 Feb 89 13:39:34 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae27758; 20 Feb 89 12:52 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25794; 20 Feb 89 12:48 EST
Received: by tektronix.TEK.COM (5.51/7.0)
	id AA06260; Mon, 20 Feb 89 09:40:33 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA15658; Mon, 20 Feb 89 09:41:01 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA10143; Tue, 21 Feb 89 09:42:45 pst
Message-Id: <8902211742.AA10143@bloom.LA.TEK.COM>
To: Chris Haynes <chaynes@IUVAX.CS.INDIANA.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: ... should be a peculiar identifier 
In-Reply-To: Your message of Sat, 18 Feb 89 21:01:37 -0500.
             <8902190215.AA25029@tektronix.TEK.COM> 
Date: Tue, 21 Feb 89 09:42:42 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET

I have used ***, but I find ... more aesthetically pleasing.
Given the backquote and number syntax, the parsing work to
recognize ... is minor.  I support ... as a peculiar identifier.

-Ken Dickey

Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 18 Feb 89 21:02:06 EST
Received: by iuvax.cs.indiana.edu 
Date: Sat, 18 Feb 89 21:01:37 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: ... should be a peculiar identifier

At the last R*RS meeting the syntactic extension committee was
strongly encouraged to come up with a proposal that provided the
functionality of extend-syntax.  Ellipsis is fundamental to that
functionality, and extend-syntax uses the standard ellipsis notation
in a way the many find highly satisfying.  Yet according to the R3RS
syntax, ... IS NOT AN IDENTIFIER.  Thus the option of providing
extend-syntax as an extension of the standard syntax is closed (unless
the property that programs parse as data is forfeited, which no one
wants to see).  I've tried to think of a presently legal identifier
that could serve in place of ..., but without luck.  Compatibility
with the existing extend-syntax is also worth something, though not
essential.  

The syntactic category <peculiar identifier> has already been provided
to make exceptions of + and -.  The problem could be fixed by simply
adding ... to the list.  This was considered and voted down at
Brandeis, but at that time the community of extend-syntax users was
much smaller and the feeling that some sort of syntactic extension
mechanisms belonged in Scheme had much less support than it does now.
I think we should reconsider this issue now so the syntactic extension
committee isn't faced with an awkward problem in the future.

If consensus can be reached over the net in next the couple of months, it
could even improve the IEEE standard.  Comments?

Chris Haynes
Dan Friedman
Mitch Wand