Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU  8 Feb 89 23:12:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa20621; 8 Feb 89 18:17 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa16772; 8 Feb 89 18:09 EST
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA01162; Wed, 8 Feb 89 11:55:22 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA18580; Wed, 8 Feb 89 11:53:35 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA01156; Thu, 9 Feb 89 11:55:49 pst
Message-Id: <8902091955.AA01156@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Portability
Date: Thu, 09 Feb 89 11:55:47 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET

POSITION:

One of Scheme's many strengths is its clear definition.  The use of
denotation semantics makes it possible to provably implement the same
semantics on very different CPU architectures.  By its nature, Scheme
should be the most portable of languages.  Indeed, standard Scheme
programs are typically ported between implementations with the same
source code and a small compaibility file.

The number of implementations is rapidly growing.  Not having a
standard library interface and not having a way to define a single
compaibility file across a large number of implementations will
shortly be a major impediment to portability.

For a moderately large and complex `program' to be portable, there
must be a baseline functionality.  Typically there will be a gap
between this baseline and the IEEE (minimalist) standard.  In order to
be able to use definitions provided by an implementation, there needs
to be a way to query implementations about environmental differences
(eg: implementation+version, OS, FS, CPU, ...) and a way to
non-intrusively add definitions--including commonly used syntactic
idioms (when, unless, ...) and optimizations (define-constant <->
define; define-integrable <-> define; herald <-> comment; error <->
cerror; ...). 

Let me give an example.  Here is a definition which maps a
machine/implementation specific function to an implementation independent
one.  Note that--as defined--all of this code gets compiled, although we
only need one of the lambda bindings.  We can get around this using
syntax/macros, but that is currently not portable!

  (define %draw-point  ; args: (x y color)
     (case <scheme-implementation>
       ((PCScheme)  (lambda (x y color) (%graphics 1 x y color 0 0 0)))
       ((MacScheme) (lambda (x y ignored) (draw-point x y)))
       ((T) ...)
       ((CScheme) ...)
       ((Skim) ...)
       ((XScheme) (case <OS> ...) ...)
       ((AmigaScheme) ...)
       ...
       (else (error "unrecognized scheme implementation" 
                    <scheme-implementation>))
  )  )
  
In addition, there is the problem of augmenting what is absent in a
non-intrusive way.  Something along the lines of:

   (define-if-needed (foo . args) body)
   ==> (unless (defined? foo)
               (define-in-enclosing-env (foo . args) body))
  

It would be nice to define an ERROR function for programatic recovery as
well as a special form (`CERROR' ?) which captures state for interactive
debugging.  It would be helpful to have a suggested interface for functions
which may be implemented but are not required (e.g. TIME should--if defined--
return the clock time in the same format for all implementations).

Anyway, it seems to me that a lot of work needs to be done here.  If done
well, we will get portable code.  If not done, we can have a real mess.

I will be happy to track proposals in this area.

Comments?  I'm sure there are comments!

-Ken			kend@mrloog.LA.TEK.COM

Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU  7 Feb 89 16:12:24 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA01849; Tue, 7 Feb 89 12:34:35 PST
Date: Tue, 7 Feb 89 12:34:35 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8902072034.AA01849@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Wed, 01 Feb 89 17:06:06 PST <890201-170617-11852@Xerox>
Subject: truth of '()

   Date: Wed, 01 Feb 89 17:06:06 PST
   From: Pavel.pa@Xerox.COM

   Morry says, ``use of PAIR?, etc. forces the programmer to specify the types
   of values he/she expects the given function to return and consequently
   informs the reader of this information''.

   This is only true if the function is expected to return several different
   kinds of values (otherwise, the test would not be necessary and thus would
   not appear).  The kinds of tests used now are precisely the same as this.
   Every time I say (if (foo) (bar) (baz)), in your system I might just say
   (if (false? (foo)) (baz) (bar)).  This doesn't tell you any more than the
   other.  When I use PAIR?, you only know that pairs are one of the
   possibilities; you have no notion of the other possibilities.  In current
   Scheme, when I say (if (foo) ...) you know that #f is one of the
   possibilities.  This seems symmetric to me.  I see no reason to prefer the
   type of pairs over the type containing only #f.

	   Pavel

The problem is that as things currently stand false is not a given object or
type, but actually a set composed of #f, '(), and maybe something else in some
implementations.  Furthermore, I can only repeat my statement that TO ME it is
much clearer when code uses the NULL? and FALSE? predicates, then when it does
not.  (I guess you just can't account for taste, but thats mine.)
					Morry Katz
					katz@polya.stanford.edu

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU  2 Feb 89 19:11:43 EST
Received: by void.ai.mit.edu (5.59/1.5)
	id AA12855; Thu, 2 Feb 89 19:15:45 EST
Date: Thu, 2 Feb 89 19:15:45 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902030015.AA12855@void.ai.mit.edu>
To: andy@ads.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Andy Cromarty's message of Wed, 1 Feb 89 10:01:58 PST <8902011801.AA05206@ads.com>
Subject: rrrs-authors vs. scheme-standard
Reply-To: jar@zurich.ai.mit.edu

   Date: Wed, 1 Feb 89 10:01:58 PST
   From: Andy Cromarty <andy@ads.com>

   ... It seems that scheme-standard and rrrs-authors are being used
   almost interchangeably; in fact, several discussions have seemed to
   bleed over from one list to the other in mid-debate as if the
   distinction does not exist.  To the extent that you still are
   active in managing the rrrs-authors list, can you comment (perhaps
   publicly) on proper use of the lists or their composition?  Perhaps
   there's near-total overlap and it doesn't matter which we use, for
   example (even that would be useful information).

Rrrs-authors is an informal anarchic non-public discussion of what is
supposed to go into the next Scheme report.  Scheme-standard is for
discussing the IEEE Scheme standard, which is supposed to be "based on
the Scheme report".  The IEEE group decided at its first meeting not
to do language design.  In principle there should be no overlap
between the subject material for the two lists.

If the IEEE group wants to do anything other than subset the report,
then I expect it will submit its proposals to rrrs-authors for
discussion.  People who would desire to add any kind of new feature
(to choose one example at random: allowing the empty list to be
considered true) to the IEEE dialect should direct their proposals to
rrrs-authors, not scheme-standard, so that they can be considered for
the language on which the IEEE document is supposed to be based.  When
in doubt, send to rrrs-authors, or, if you're not on rrrs-authors, to
the Scheme list.

The editors of the IEEE draft standard have some small changes that
they would like to propose for the report.  Not to worry; those
changes will be forwarded to the rrrs-authors list in due time.

Of course, subsetting discussions can be quite heated, as those who
are on the scheme-standard list have recently observed.

Received: from chamartin.ai.mit.edu (TCP 2212600253) by MC.LCS.MIT.EDU  2 Feb 89 16:42:56 EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
	id AA06699; Thu, 2 Feb 89 16:28:34 EST
Date: Thu, 2 Feb 89 16:28:34 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902022128.AA06699@chamartin.ai.mit.edu>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Wed, 1 Feb 89 17:32 EST <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: truth of '()
Reply-To: jinx@zurich.ai.mit.edu


    I don't recall that we have any consensus for eventually declaring that
    implementations -must- have distinct () and #F objects.  My understanding
    is that making the boolean significance of () unspecified is to accommodate
    implementations in which they are distinct, where it might be inconvenient
    to arrange for () to be false.  

I agree completely with Alan.  I might encourage implementors and
dialect designers to distinguish () and #f.  I might even distinguish
them myself if I were designing a new dialect, but I would never agree
to forcing them to be distinct.

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  2 Feb 89 16:36:45 EST
Received: from chamartin.ai.mit.edu by XX.LCS.MIT.EDU with TCP/SMTP; Thu 2 Feb 89 16:37:41-EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
	id AA06704; Thu, 2 Feb 89 16:33:43 EST
Date: Thu, 2 Feb 89 16:33:43 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902022133.AA06704@chamartin.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 Wed, 01 Feb 89 14:55:40 PST <890201-145551-11497@Xerox>
Subject: Quoting vectors?
Reply-To: jinx@zurich.ai.mit.edu


    Sussman says that he ``cannot remember ever trying to use bare () in a
    program''.  The only explanation I can give for this is the fact that the
    initial value of NIL is #f and that, in C-Scheme, #f and () are identical.

NIL is not bound by default in C-Scheme.  GJS, like many other MIT
Scheme programmers, including myself, use "'()" or "#f" (even "'#f")
depending on intent.  The C Scheme reader happens to read them as
the same object, but that does not mean that the user knowingly or
intentionally depended on that fact for his program to work.

Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  2 Feb 89 15:38:44 EST
Received: from kleph.ai.mit.edu ([18.43.0.172]) by XX.LCS.MIT.EDU with TCP/SMTP; Thu 2 Feb 89 15:36:54-EST
Received: by kleph.ai.mit.edu (5.59/1.5)
	id AA00381; Thu, 2 Feb 89 14:09:27 EST
Date: Thu, 2 Feb 89 14:09:27 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8902021909.AA00381@kleph.ai.mit.edu>
To: andy@polya.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Andy Freeman's message of Thu, 2 Feb 89 10:40:06 -0800 <8902021840.AA02726@polya.Stanford.EDU>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu

   Date: Thu, 2 Feb 89 10:40:06 -0800
   From: Andy Freeman <andy@polya.Stanford.EDU>

   Of course, one could argue that the opposite view, that quotation is a
   hack to make up for the unfortunate fact that lists and symbols use
   the same syntax as expressions and variables.  I don't like this
   because it makes quasi-quote into another hack, and I don't think that
   either quasi-quote or quote are hacks.

Actually, if you look into this a little (I'd suggest talking to John
Lamping) it becomes pretty obvious that they are both hacks.  Fixing
it, unfortunately, requires some pretty serious changes to the
language.

Received: from polya.Stanford.EDU (TCP 4402000240) by MC.LCS.MIT.EDU  2 Feb 89 13:39:38 EST
Received:  by polya.Stanford.EDU (5.61/25-eef) id AA02726; Thu, 2 Feb 89 10:40:06 -0800
Date: Thu, 2 Feb 89 10:40:06 -0800
From: Andy Freeman <andy@polya.Stanford.EDU>
Message-Id: <8902021840.AA02726@polya.Stanford.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Pavel.pa@Xerox.COM's message of Wed, 01 Feb 89 17:28:09 PST <890201-172921-11917@Xerox>
Subject: Quoting vectors?

Pavel writes:
>I see no reason to force all Scheme programmers to write logically
>unnecessary quotes in order to allow this obscure and, to my knowledge,
>rarely if ever employed, avenue for experimentation.

It turns out that I defined and played with a parallel scheme that
used vectors instead of lists almost everywhere.

Another way of looking at this question is by counting the number of
rules required to figure out whether or not a quote is necessary.  I
personally favor required quotes on all data objects with strings and
numbers as special cases because of historical reasons (and '" looks
dumb).  This not only means that we can decide later how to determine
the value of something that currently only has a data syntax, but that
the rules for finding non-data, is it quoted, are quite simple.

Of course, one could argue that the opposite view, that quotation is a
hack to make up for the unfortunate fact that lists and symbols use
the same syntax as expressions and variables.  I don't like this
because it makes quasi-quote into another hack, and I don't think that
either quasi-quote or quote are hacks.  It also means that we're tied
into the current syntax for non-data and everything else is data,
which is a little more complicated than the current rule.

(BTW - I wonder if an individual's views on required quotes correlates
with their views on the truth values.)

-andy

Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU  1 Feb 89 23:44:08 EST
Received: by iuvax.cs.indiana.edu 
Date: Wed, 1 Feb 89 23:24:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu
Subject: with-input-from-file and co.
Cc: rrrs-authors@mc.lcs.mit.edu

I have never felt that "with-input-from-file" and "with-output-to-file"
were a good thing, and I would like to see them flushed from R4RS.
Whether or not this happens, I would certainly rather see them omitted
from the standard.  This goes for the proposed "with-input-from-port"
and "with-output-to-port" procedures as well.  I don't think that it is
a good idea to encourage rebinding of these ports, especially if we are
not going to specify what happens when an escape procedure is invoked.
It would mean that every independent subcomputation that may need to
read from or write to the original ports would have to stash a copy of
the port for itself to use explicitly.  Bugs resulting from this sort
of problem are difficult to track down ... especially for those in the
habit of adding "print" statements for debugging purposes.

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 22:46:10 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 09:18:40 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 22:45:21 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 08:42:56 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 22:43:34 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 10:48:42 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 22:40:30 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 16:13:32 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 16:13:23 PDT
Date: Wed, 1 Feb 89 16:13:23 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902020013.AA16093@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: apology for flamage concerning WITH-INPUT-FROM-PORT etc

Please disregard my earlier flamage concerning WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT.  I was just moby confused, having somehow gotten it
deeply wedged into my brain that these procedures were replacing
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE when they are really
replacing WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE.  The proposed
procedures are clearly superior to the ones they replace, and the only
possible question is whether this particular bit of functionality, which
was optional in R3RS, should go into the IEEE standard.

I certainly favor making this change in R4RS.

Please accept my apologies for thoughtlessly polluting this mailing list
with nonsense.

Peace, William Clinger

P.S. with regard to whether vector constants should have to be quoted:
As things stand now, implementations are free to allow unquoted vector
constants, and several do.  Does the recent discussion mean that this
this feature is causing so many portability problems that it should be
required of all implementations?

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU  1 Feb 89 22:26:45 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 17:06:17 PST
Date: Wed, 01 Feb 89 17:06:06 PST
From: Pavel.pa@Xerox.COM
Subject: Re: truth of '()
In-reply-to: <8902011754.AA14758@sesame.Stanford.EDU>
To: mkatz@sesame.stanford.edu (Morris Katz)
Cc: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890201-170617-11852@Xerox>

Morry says, ``use of PAIR?, etc. forces the programmer to specify the types
of values he/she expects the given function to return and consequently
informs the reader of this information''.

This is only true if the function is expected to return several different
kinds of values (otherwise, the test would not be necessary and thus would
not appear).  The kinds of tests used now are precisely the same as this.
Every time I say (if (foo) (bar) (baz)), in your system I might just say
(if (false? (foo)) (baz) (bar)).  This doesn't tell you any more than the
other.  When I use PAIR?, you only know that pairs are one of the
possibilities; you have no notion of the other possibilities.  In current
Scheme, when I say (if (foo) ...) you know that #f is one of the
possibilities.  This seems symmetric to me.  I see no reason to prefer the
type of pairs over the type containing only #f.

	Pavel

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU  1 Feb 89 22:26:29 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 17:29:21 PST
Date: Wed, 01 Feb 89 17:28:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8902021955.AA11596@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <890201-172921-11917@Xerox>

In reference to Ken Dickey's argument that vectors should be quoted in
order to allow experimentation with new dialects that want to use vectors
as some other kind of syntax:

I've never understood this point of view.  Ken mentions the idea of #(foor
bar baz) being another syntax for application in a dialect in which one
could get a ``rest'' argument as a vector.  Clearly, the data type used to
represent the expression need not have anything to do with the data types
used to implement the evaluation of that expression, so the availability of
vector ``rest'' arguments is completely orthogonal to the use of vectors as
a kind of expression.

I see no reason to force all Scheme programmers to write logically
unnecessary quotes in order to allow this obscure and, to my knowledge,
rarely if ever employed, avenue for experimentation.

	Pavel

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU  1 Feb 89 22:08:22 EST
Received: by void.ai.mit.edu (5.59/1.5)
	id AA12393; Wed, 1 Feb 89 21:09:06 EST
Date: Wed, 1 Feb 89 21:09:06 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902020209.AA12393@void.ai.mit.edu>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Wed, 1 Feb 89 17:32 EST <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: truth of '()
Reply-To: jar@zurich.ai.mit.edu

   Date: Wed, 1 Feb 89 17:32 EST
   From: Alan Bawden <Alan@AI.AI.MIT.EDU>

   1.  I don't have any problem with leaving the boolean significance of ()
       unspecified.   

Clarification: the Revised^3 Report (section 6.1) does not leave the
boolean significance of () unspecified; it says explicitly that ()
must be treated as false.  It was proposed last July (item 4.25 of
"Proposals for a Revised^4 Scheme Report") that this be relaxed so
that () could be treated as either true or false.  We ran out of time
before we could get around to considering this item.  That is why I
brought it up again.

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU  1 Feb 89 22:08:02 EST
Received: by void.ai.mit.edu (5.59/1.5)
	id AA12400; Wed, 1 Feb 89 21:22:59 EST
Date: Wed, 1 Feb 89 21:22:59 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902020222.AA12400@void.ai.mit.edu>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: William Clinger's message of Wed, 1 Feb 89 08:13:37 PDT <8902011613.AA14233@fog.cs.uoregon.edu>
Subject:  Quoting vectors?
Reply-To: jar@zurich.ai.mit.edu

My recollection agrees with Will's.  Vectors should be quoted because
they look and feel like lists.  Empty lists should be quoted for
consistency with other kinds of lists.  When in doubt, quote.

I have made use of both restrictions.  I would prefer that we be
conservative and not change the language in these cases.

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU  1 Feb 89 19:38:47 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 14:55:51 PST
Date: Wed, 01 Feb 89 14:55:40 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8902011500.AA13458@zohar>
To: rrrs-authors@mc.lcs.mit.EDU
Message-ID: <890201-145551-11497@Xerox>

Sussman says that he ``cannot remember ever trying to use bare () in a
program''.  The only explanation I can give for this is the fact that the
initial value of NIL is #f and that, in C-Scheme, #f and () are identical.

Thus, it might be that he never uses () because he always uses NIL in such
a case.  I seem to remember seeing such cases in SICP.

	Pavel

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 19:18:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 16:18:45 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 16:13:23 PDT
Date: Wed, 1 Feb 89 16:13:23 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902020013.AA16093@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: apology for flamage concerning WITH-INPUT-FROM-PORT etc

Please disregard my earlier flamage concerning WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT.  I was just moby confused, having somehow gotten it
deeply wedged into my brain that these procedures were replacing
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE when they are really
replacing WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE.  The proposed
procedures are clearly superior to the ones they replace, and the only
possible question is whether this particular bit of functionality, which
was optional in R3RS, should go into the IEEE standard.

I certainly favor making this change in R4RS.

Please accept my apologies for thoughtlessly polluting this mailing list
with nonsense.

Peace, William Clinger

P.S. with regard to whether vector constants should have to be quoted:
As things stand now, implementations are free to allow unquoted vector
constants, and several do.  Does the recent discussion mean that this
this feature is causing so many portability problems that it should be
required of all implementations?

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 18:40:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 09:48:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU  1 Feb 89 17:32:47 EST
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 170157; Wed 1-Feb-89 17:32:10 EST
Date: Wed, 1 Feb 89 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: truth of '()
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <890131-183948-9423@Xerox>
Message-ID: <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>

My opinions:

1.  I don't have any problem with leaving the boolean significance of ()
    unspecified.   

2.  I am strongly in favor of retaining the fine Lisp tradition
    of treating everything other than () and #F as truth.

My concern:

    Date: Tue, 31 Jan 89 18:39:37 PST
    From: Pavel.pa@Xerox.COM
    I certainly support unspecifying the truth-value of the empty list.  Unlike
    Ken Dickey, I don't feel the need for an immediate change to specifying
    that () is true, either.  I'm perfectly willing to give implementations one
    more bounce of the report to get switched over.

I don't recall that we have any consensus for eventually declaring that
implementations -must- have distinct () and #F objects.  My understanding
is that making the boolean significance of () unspecified is to accommodate
implementations in which they are distinct, where it might be inconvenient
to arrange for () to be false.  It is not my understanding that we are
doing this as a stepping stone on the way towards defining () to be true
(which would force () to be distinct from #F).

Please note that this concern of mine has no effect on the current
discussion about ().

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU  1 Feb 89 16:03:45 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07115; 1 Feb 89 15:26 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25646; 1 Feb 89 15:20 EST
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA20669; Wed, 1 Feb 89 11:54:46 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA06172; Wed, 1 Feb 89 11:53:41 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA11596; Thu, 2 Feb 89 11:55:50 pst
Message-Id: <8902021955.AA11596@bloom.LA.TEK.COM>
To: Mitchell Wand <wand@CORWIN.CCS.NORTHEASTERN.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: Quoting vectors? 
In-Reply-To: Your message of Tue, 31 Jan 89 15:20:09 -0500.
             <8901312020.AA17812@corwin.CCS.Northeastern.EDU> 
Date: Thu, 02 Feb 89 11:55:47 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET

Mitch,

As I remember it, the reason given for quoting vectors is that a case could
be made for a Scheme dialect in which #(foo bar baz) is seen as a function
application analogous to (foo bar baz).  In such a dialect there might, for
example, be a `rest' argument which was a vector. 
E.g.:
  ((lambda (a b #. c) c) '(1 2 3 4 5 6)) ==> #(3 4 5 6)
etc.

I see no reason to force an implementation which experiments in this way not
be called Scheme on the basis of a single difference from a standard. 


-Ken Dickey

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 14:44:22 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 10:18:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 14:18:51 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 11:18:42 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc

       Date: Tue, 31 Jan 89 13:46:07 PDT
       From: William Clinger <will@fog.cs.uoregon.edu>

       I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
       WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a
       way to change the default ports is that some people do not want them to
       be changable.  Furthermore the implementation-dependent behavior of
       these new procedures is a serious problem because they muck with a
       global resource: the default ports....

    Date: Tue, 31 Jan 89 20:51:41 EST
    From: cph@murren.ai.mit.edu (Chris Hanson)

    This shouldn't be an issue.  The procedures `with-input-from-file' and
    `with-output-to-file' already do this kind of binding.  What we're
    suggesting isn't new functionality, but a subset of existing
    functionality: we want the binding part of `with-...-file' separately
    from the file-opening part.

Right.  I was confused.  But now that I'm not, I'm more concerned than
before.  WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined.  Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme.  On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.

Peace, Will

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU  1 Feb 89 13:43:50 EST
Received: from fafnir.think.com by Think.COM; Wed, 1 Feb 89 12:48:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 1 Feb 89 12:54:03 EST
Received: by verdi.think.com; Wed, 1 Feb 89 12:53:36 EST
Date: Wed, 1 Feb 89 12:53:36 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902011753.AA14984@verdi.think.com>
To: jinx@zurich.ai.mit.edu
Cc: gjs@zohar.ai.mit.edu, cph@zurich.ai.mit.edu,
        wand@corwin.ccs.northeastern.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 1 Feb 89 08:46:38 EST <8902011346.AA05917@chamartin.ai.mit.edu>
Subject: Quoting vectors?

   Date: Wed, 1 Feb 89 08:46:38 EST
   From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)


       I would rather that vectors (and all objects that cannot be confused
       with expressions) not need quotes, as the only reason for quotes is to
       distinguish expressions from their values.

   You've all forgotten a little detail.

   `#(foo ,bar baz ,@quux)

   is legal.  It would be REALLY strange if a constant vector did not
   need to be quoted when a "quasi-constant" vector did.

I think there may be a confusion here between two distinct properties
of a data object: whether or not it self-evaluates, and whether or
not is has (Lisp) substructure.

It is hard to work from analogy, because all other self-evaluating items
happen also to have the property of having no substructure, so I cannot
give you a plausible example of, for example, a quasi-quoted integer.

In the context of Common Lisp I might offer the fact that the complex
number #c(0 1) does not require quotation, but `#c(0 ,x) might be a
reasonable thing to want to write (though in fact it is not permitted in
Common Lisp).

--Guy

Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU  1 Feb 89 13:26:51 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA14758; Wed, 1 Feb 89 09:54:22 PST
Date: Wed, 1 Feb 89 09:54:22 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8902011754.AA14758@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 31 Jan 89 18:39:37 PST <890131-183948-9423@Xerox>
Subject: truth of '()

   Date: Tue, 31 Jan 89 18:39:37 PST
   From: Pavel.pa@Xerox.COM

   I certainly support unspecifying the truth-value of the empty list.  Unlike
   Ken Dickey, I don't feel the need for an immediate change to specifying
   that () is true, either.  I'm perfectly willing to give implementations one
   more bounce of the report to get switched over.

   Morry Katz is strongly in favor of unspecifying the truth-values of
   non-booleans.  This has never appealed to me.  Morry, could you provide
   more extensive support for your view that the ``resulting code would ... be
   much easier to read and less error prone''?  I'm not convinced that the
   status quo in this case is an example of ``traditionally poor semantics''.

	   Pavel


Currently, there are a lot of functions that do things like return a list or
nil, if no match is found.  I think that it would be much clearer to the reader
if such a function were wrapped in a call to NULL? when used as a predicate.
Similar use of PAIR?, etc. forces the programmer to specify the types of values
he/she expects the given function to return and consequently informs the reader
of this information.  I find such code mush easier to read.  Maybe this is just
my hangup, but the use of all objects as boolean values seems to me a little
like a type error.  My personal perspective is that asking whether '() and #f
are eq? is a little like asking whether (char? 13) returns #t.  Types should
really be disjoint and this includes the boolean values #t and #f.
					Morry Katz
					katz@polya.stanford.edu

Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU  1 Feb 89 13:14:12 EST
Received: by iuvax.cs.indiana.edu 
Date: Wed, 1 Feb 89 10:38:46 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx@ZURICH.AI.MIT.EDU
Subject: Re:  Quoting vectors?
Cc: rrrs-authors@mc.lcs.mit.edu

>    I would rather that vectors (and all objects that cannot be confused
>    with expressions) not need quotes, as the only reason for quotes is to
>    distinguish expressions from their values.
>
>You've all forgotten a little detail.
>
>`#(foo ,bar baz ,@quux)
>
>is legal.  It would be REALLY strange if a constant vector did not
>need to be quoted when a "quasi-constant" vector did.

I agree.  It would be strange.  However, we could look at this is an
opportunity to remove vectors from quasiquote...

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  1 Feb 89 11:14:32 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 08:13:46 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:13:37 PDT
Date: Wed, 1 Feb 89 08:13:37 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011613.AA14233@fog.cs.uoregon.edu>
To: rrrs-authors@MC.LCS.MIT.EDU, wand@CORWIN.CCS.NORTHEASTERN.EDU
Subject: Re:  Quoting vectors?

My recollection is that there were two principled positions (everything
must be explicitly quoted; or only lists and symbols must be quoted) and
that we chose to be close to the "everything must be explicitly quoted"
position, making exceptions for #T, #F, numbers, and strings (presumably
because of historical precedent not only in Lisp but in other
languages).  Vectors were considered for self-evaluating status, but the
lack of historical precedent and their syntactic similarity to lists
successfully argued against.

Peace, Will

Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU  1 Feb 89 11:11:32 EST
Received: by kleph.ai.mit.edu (5.59/1.5)
	id AA08769; Wed, 1 Feb 89 09:57:10 EST
Date: Wed, 1 Feb 89 09:57:10 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8902011457.AA08769@kleph.ai.mit.edu>
To: jinx@zurich.ai.mit.edu
Cc: gjs@ZOHAR.AI.MIT.EDU, wand@corwin.ccs.northeastern.edu,
        rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 1 Feb 89 08:46:38 EST <8902011346.AA05917@chamartin.ai.mit.edu>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu

   Date: Wed, 1 Feb 89 08:46:38 EST
   From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)

   You've all forgotten a little detail.

   `#(foo ,bar baz ,@quux)

   is legal.  It would be REALLY strange if a constant vector did not
   need to be quoted when a "quasi-constant" vector did.

I don't believe this small bit of consistency is very important.
After all, even if quote is not required on vector constants, it is
still allowed.

As to its being REALLY strange, MIT Scheme does it just that way, and
aside from the fact that it is a completely natural implementation, I
don't think anyone has ever run into any confusion because of the lack
of that requirement.

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU  1 Feb 89 11:11:03 EST
Received: from Salvador.ms by ArpaGateway.ms ; 31 JAN 89 18:39:48 PST
Date: Tue, 31 Jan 89 18:39:37 PST
From: Pavel.pa@Xerox.COM
Subject: Re: truth of '()
In-reply-to: <8901311743.AA13348@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890131-183948-9423@Xerox>

I certainly support unspecifying the truth-value of the empty list.  Unlike
Ken Dickey, I don't feel the need for an immediate change to specifying
that () is true, either.  I'm perfectly willing to give implementations one
more bounce of the report to get switched over.

Morry Katz is strongly in favor of unspecifying the truth-values of
non-booleans.  This has never appealed to me.  Morry, could you provide
more extensive support for your view that the ``resulting code would ... be
much easier to read and less error prone''?  I'm not convinced that the
status quo in this case is an example of ``traditionally poor semantics''.

	Pavel

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU  1 Feb 89 11:10:44 EST
Received: from Salvador.ms by ArpaGateway.ms ; 31 JAN 89 18:32:04 PST
Date: Tue, 31 Jan 89 18:31:49 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8901312149.AA12923@zohar>
To: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Cc: rrrs-authors@mc.lcs.mit.EDU
Message-ID: <890131-183204-9404@Xerox>

     I would rather that ... all objects that cannot be confused
     with expressions ... not need quotes ...

I assume that this includes (), since it also fits into this category.

	Pavel

Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU  1 Feb 89 11:10:00 EST
Received: by ZOHAR.AI.MIT.EDU; Wed, 1 Feb 89 10:00:13 est
Date: Wed, 1 Feb 89 10:00:13 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8902011500.AA13458@zohar>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.EDU
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 31 Jan 89 18:31:49 PST <890131-183204-9404@Xerox>
Subject: Quoting vectors?



	  I would rather that ... all objects that cannot be confused
	  with expressions ... not need quotes ...

     I assume that this includes (), since it also fits into this category.

Well, almost all, but I really don't care about the disposition of (),
I cannot remember ever trying to use bare () in a program.
   ... Well, hardly ever ... 
             The Captian of the Pinafore.

Received: from chamartin.ai.mit.edu (TCP 2212600253) by MC.LCS.MIT.EDU  1 Feb 89 09:12:45 EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
	id AA05917; Wed, 1 Feb 89 08:46:38 EST
Date: Wed, 1 Feb 89 08:46:38 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902011346.AA05917@chamartin.ai.mit.edu>
To: gjs@ZOHAR.AI.MIT.EDU
Cc: cph@zurich.ai.mit.edu, wand@corwin.ccs.northeastern.edu,
        rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Tue, 31 Jan 89 16:49:17 est <8901312149.AA12923@zohar>
Subject: Quoting vectors?
Reply-To: jinx@zurich.ai.mit.edu


    I would rather that vectors (and all objects that cannot be confused
    with expressions) not need quotes, as the only reason for quotes is to
    distinguish expressions from their values.

You've all forgotten a little detail.

`#(foo ,bar baz ,@quux)

is legal.  It would be REALLY strange if a constant vector did not
need to be quoted when a "quasi-constant" vector did.


Received: from murren.ai.mit.edu (TCP 2212600263) by MC.LCS.MIT.EDU 31 Jan 89 20:59:03 EST
Received: by murren.ai.mit.edu (5.59/1.5)
	id AA20427; Tue, 31 Jan 89 20:51:41 EST
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
Message-Id: <8902010151.AA20427@murren.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, 31 Jan 89 13:46:07 PDT <8901312146.AA10918@fog.cs.uoregon.edu>
Subject: comments on draft IEEE std
Reply-To: cph@zurich.ai.mit.edu

   Date: Tue, 31 Jan 89 13:46:07 PDT
   From: William Clinger <will@fog.cs.uoregon.edu>

   I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
   WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
   to change the default ports is that some people do not want them to be
   changable.  Furthermore the implementation-dependent behavior of these
   new procedures is a serious problem because they muck with a global
   resource: the default ports.  The implementation-dependent behavior of
   CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
   therefore less troublesome.

This shouldn't be an issue.  The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding.  What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:27:47 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 16:48:33 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:27:15 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 16:18:34 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:26:01 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 15:48:31 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:25:34 EST
Received: from [128.223.4.2] by mist.math.uoregon.edu; Tue, 31 Jan 89 14:53:54 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std

   Date: Fri, 27 Jan 89 14:46:12 PST
   From: Pavel.pa@Xerox.COM

   I note with some misgivings several differences between R4RS and the draft
   IEEE standard such that the standard is not a subset of R4RS....

I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS.  There are only two things in the draft
IEEE standard that might not belong in the R4RS:

  WITH-INPUT-FROM-PORT
  WITH-OUTPUT-TO-PORT

Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS.  (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)

I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.

The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER.  If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.

The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.

Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer.  (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part.  Does anyone disagree?)  I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.

Peace, Will
acting editor, R4RS


Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:25:04 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:49:03 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std

   Date: Fri, 27 Jan 89 14:46:12 PST
   From: Pavel.pa@Xerox.COM

   I note with some misgivings several differences between R4RS and the draft
   IEEE standard such that the standard is not a subset of R4RS....

I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS.  There are only two things in the draft
IEEE standard that might not belong in the R4RS:

  WITH-INPUT-FROM-PORT
  WITH-OUTPUT-TO-PORT

Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS.  (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)

I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.

The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER.  If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.

The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.

Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer.  (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part.  Does anyone disagree?)  I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.

Peace, Will
acting editor, R4RS


Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:24:31 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:45:23 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std

   Date: Fri, 27 Jan 89 14:46:12 PST
   From: Pavel.pa@Xerox.COM

   I note with some misgivings several differences between R4RS and the draft
   IEEE standard such that the standard is not a subset of R4RS....

I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS.  There are only two things in the draft
IEEE standard that might not belong in the R4RS:

  WITH-INPUT-FROM-PORT
  WITH-OUTPUT-TO-PORT

Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS.  (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)

I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.

The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER.  If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.

The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.

Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer.  (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part.  Does anyone disagree?)  I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.

Peace, Will
acting editor, R4RS


Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:24:02 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:48:32 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:23:36 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:46:15 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:18:46 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 17:18:32 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std

I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS).  Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.

I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures.  One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable.  Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports.  The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.

I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics.  Jonathan's code is great
but too specific.  Maybe the code could go in a non-binding appendix?

I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.

One person's random opinions.  Peace, Will

Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 31 Jan 89 20:09:52 EST
Received: by ZOHAR.AI.MIT.EDU; Tue, 31 Jan 89 16:49:17 est
Date: Tue, 31 Jan 89 16:49:17 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8901312149.AA12923@zohar>
To: cph@zurich.ai.mit.edu
Cc: wand@corwin.ccs.northeastern.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 31 Jan 89 15:34:39 EST <8901312034.AA08459@kleph.ai.mit.edu>
Subject: Quoting vectors?

I would rather that vectors (and all objects that cannot be confused
with expressions) not need quotes, as the only reason for quotes is to
distinguish expressions from their values.

Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU 31 Jan 89 15:37:20 EST
Received: by kleph.ai.mit.edu (5.59/1.5)
	id AA08459; Tue, 31 Jan 89 15:34:39 EST
Date: Tue, 31 Jan 89 15:34:39 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8901312034.AA08459@kleph.ai.mit.edu>
To: wand@corwin.ccs.northeastern.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Tue, 31 Jan 89 15:20:09 EST <8901312020.AA17812@corwin.CCS.Northeastern.EDU>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu

   Date: Tue, 31 Jan 89 15:20:09 EST
   From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>

   Does anyone remember why we decided to force vectors to be quoted, while #t
   and #f and character constants need not be quoted?

I don't remember why, but I believe this was an unnecessary decision.
Leaving out the quote causes no confusion.

Received: from helios.northeastern.edu (TCP 20102400402) by MC.LCS.MIT.EDU 31 Jan 89 15:26:51 EST
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
          id aa17133; 31 Jan 89 15:21 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.5)
	id AA17812; Tue, 31 Jan 89 15:20:09 EST
Date: Tue, 31 Jan 89 15:20:09 EST
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8901312020.AA17812@corwin.CCS.Northeastern.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Quoting vectors?

Does anyone remember why we decided to force vectors to be quoted, while #t
and #f and character constants need not be quoted?

--Mitch

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 31 Jan 89 14:54:43 EST
Received: from relay2.cs.net by RELAY.CS.NET id aj15334; 31 Jan 89 13:48 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa13406; 31 Jan 89 13:29 EST
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA13589; Tue, 31 Jan 89 09:05:13 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA04919; Tue, 31 Jan 89 09:04:11 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA10814; Wed, 1 Feb 89 09:06:20 pst
Message-Id: <8902011706.AA10814@bloom.LA.TEK.COM>
To: jar@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: truth of '() 
In-Reply-To: Your message of Tue, 31 Jan 89 10:54:04 -0500.
             <8901311554.AA11770@void.ai.mit.edu> 
Date: Wed, 01 Feb 89 09:06:17 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET

I would prefer that '() be true always.  I think that the question should be
`why should anything other than #f be false?'.  While I understand the
historical arguments and sympathize with implementors, I feel that having
(if '() #t #f) return #t or #f depending on the implementation will be bad
for the language.  It will be an irritation for a long time if this is not
decided now; a hinderance to portability.

-Ken Dickey	kend@mrloog.LA.TEK.COM

Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 31 Jan 89 12:45:01 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA13348; Tue, 31 Jan 89 09:43:37 PST
Date: Tue, 31 Jan 89 09:43:37 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8901311743.AA13348@sesame.Stanford.EDU>
To: jar@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan Rees's message of Tue, 31 Jan 89 10:54:04 EST <8901311554.AA11770@void.ai.mit.edu>
Subject: truth of '()

   Date: Tue, 31 Jan 89 10:54:04 EST
   From: jar@void.ai.mit.edu (Jonathan Rees)
   Reply-To: jar@zurich.ai.mit.edu

   Does anyone out there seriously object to allowing the empty list to be
   considered true?  That is, permit implementations to return either #t or
   #f for  (if '() #t #f).
   I think we just didn't get around to discussing this at Snowbird, and
   I have the impression that we are ready to make this change.

   I hope we can make language decisions (at least provisionally) on this
   mailing list, without having to wait for meetings.

My understanding of the discussion at Snowbird was that it was decided that '()
and #f were not necessarily eq? in all implementations.  There is no point in
allowing this distinction if '() cannot be considered a `true value' in systems
which distinguish the two objects.  I therefore strongly urge that the truth
value of '() be unspecified.  

Going one step further, I once again must suggest that the truth values of all
objects other than #f and #t should be unspecified.  Functions FALSE? and TRUE?
should be introduced into the language ((FALSE? N) returns #t when N is #f, #f
otherwise; and (TRUE? N) returns #t when N is #t, #f otherwise).  These
procedures along with the existing ones like NULL?, PAIR?, etc. would allow all
the necessary boolean conditions to be expressed and canonicalized for use with
IF, etc.  The resulting code would, in my opinion, be much easier to read and
less error prone.  Since I suspect that compatability with old code is the
major impediment to people agreeing to such a change, let me suggest that the
old semantics booleans can easily be retrieved from the new by using a few
simple macros for IF, etc.  (While we still haven't managed to standardize
macros, I am sure that all existing Scheme systems have them, so backwards
compatability is possible in this manner.)  Lets not get hung up on history,
but rather fix this traditionally poor semantics.

					Morry Katz
					katz@polya.stanford.edu

Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 31 Jan 89 10:49:19 EST
Received: by void.ai.mit.edu (5.59/1.5)
	id AA11770; Tue, 31 Jan 89 10:54:04 EST
Date: Tue, 31 Jan 89 10:54:04 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8901311554.AA11770@void.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: truth of '()
Reply-To: jar@zurich.ai.mit.edu

Does anyone out there seriously object to allowing the empty list to be
considered true?  That is, permit implementations to return either #t or
#f for  (if '() #t #f).
I think we just didn't get around to discussing this at Snowbird, and
I have the impression that we are ready to make this change.

I hope we can make language decisions (at least provisionally) on this
mailing list, without having to wait for meetings.

Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 12 Jan 89 15:54:47 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac01776; 12 Jan 89 15:29 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25410; 12 Jan 89 15:14 EST
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA09013; Thu, 12 Jan 89 11:14:26 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA08476; Thu, 12 Jan 89 11:13:59 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA03876; Thu, 12 Jan 89 11:15:57 pst
Message-Id: <8901121915.AA03876@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: scheme-standard@WHEATIES.AI.MIT.EDU
Subject: R4RS Number Syntax
Date: Thu, 12 Jan 89 11:15:53 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET

I have not seen mail in some time, so I though I would send some.

It seems to me that the sharp (#) character is somewhat overused used in
number syntax.  I would like to see some character other than sharp used to
denote `extra digits'.  I would prefer dollar ($) or question (?) for their
mnemonic value.  Could one of these be excluded from special-initials?  Bar
(|) is not in the extended alphabetics, but looks ugly to me.

Comments? Suggestions?


Ken Dickey	<note change of email address>> kend@mrloog.LA.TEK.COM

PS: Any consensus on nice names for reckless rec-lets (er, named LETs)?

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  6 Nov 88 17:56:59 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Sun, 6 Nov 88 14:56:31 PDT
Received: by fog.cs.uoregon.edu; Sun, 6 Nov 88 14:56:24 PDT
Date: Sun, 6 Nov 88 14:56:24 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8811062256.AA00951@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: R4RS number syntax

Here is the new number syntax for R4RS.  I wrote a reference
parser for it and found one minor glitch, which I don't want
to try to fix.  It seems to take about three hundred lines
of commented Scheme code to parse numbers while building the
correct value and exactness.

Some examples of numbers:
    #E#o-1234
    #X#I-50
    #e#x-00abc/34
    #e#d-1###.###L-06@-.4##f+0000003
    4+5i
    +45i
    +i
    -i
    00##       (this is the glitch I found; see below)

Some examples of non-numbers:
    -#x1       (sign must follow radix and exactness prefixes)
    1/2e4      (exponents not allowed with ratio syntax)
    #b101e3    (exponents illegal if radix is not decimal)
    #x3.4      (decimal point illegal if radix is not decimal)
    45i        (sign required in front of imaginary part)
    i          (sign required)
    3#.4       (insouciant digits can't be followed by souciant)
    ##         (an insouciant digit can't be the first)

Some examples of semantics:
    1e6        is equivalent to 1000000.0 and should be inexact
    #e1e6      is equivalent to 1000000
    #i3/4      is equivalent to .75
    3/4        is equivalent to (/ 3 4)
    4+0i       is equivalent to 4
    4-6.3i     is equivalent to (make-rectangular 4 -6.3)
    123@.41    is equivalent to (make-polar 123 .41)
    1###       is equivalent to 1000.0
    00##       is equivalent to 0.0
    5.         is equivalent to 5.0

Peace, Will

Number syntax for R4RS

<number>  -->  <num 2>  |  <num 8>  |  <num 10>  |  <num 16>

The following rules for <num R>, <complex R>, <real R>, <ureal R>,
<uinteger R>, and <prefix R> should be replicated for R = 2, 8, 10,
and 16.  There are no rules for <decimal 2>, <decimal 8>, and
<decimal 16>, which means that numbers containing decimal points
or exponents must be in decimal radix.

<num R>  -->  <prefix R> <complex R>
<complex R>  -->  <real R>
    |  <real R> @ <real R>
    |  <real R> + <ureal R> i
    |  <real R> - <ureal R> i
    |  <real R> + i
    |  <real R> - i
    |  + <ureal R> i
    |  - <ureal R> i
    |  + i
    |  - i
<real R>  -->  <sign> <ureal R>
<ureal R>  -->  <uinteger R>
    |  <uinteger R> / <uinteger R>
    |  <decimal R>
<decimal 10>  -->  <uinteger 10> <suffix>
    |  . <digit 10>+ #* <suffix>
    |  <digit 10>+ . <digit 10>* #* <suffix>
    |  <digit 10>+ #* . #* <suffix>
<uinteger R>  -->  <digit R>+ #*
<prefix R>  -->  <radix R> <exactness>
    |  <exactness> <radix R>

<suffix>  -->  <empty>
    |  <exponent marker> <sign> <digit>+
<exponent marker>  -->  e  |  s  |  f  |  d  |  l
<sign>  -->  <empty>  |  +  |  -
<exactness>  -->  <empty>  |  #i  |  #e
<radix 2>  -->  #b
<radix 8>  -->  #o
<radix 10>  -->  <empty>  |  #d
<radix 16>  -->  #x
<digit 2>  -->  0  |  1
<digit 8>  -->  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7
<digit 10>  -->  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9
<digit 16>  -->  <digit 10>  |  a  |  b  |  c  |  d  |  e  |  f

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  1 Nov 88 08:48:13 EST
Received: from mitre-bedford.arpa by RELAY.CS.NET id aa23897; 1 Nov 88 7:44 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA15587; Tue, 1 Nov 88 07:34:29 EST
Posted-Date: Tue, 1 Nov 88 07:38:27 EST
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA05549; Tue, 1 Nov 88 07:38:27 EST
Date: Tue, 1 Nov 88 07:38:27 EST
From: ramsdell%linus@MITRE-BEDFORD.ARPA
Message-Id: <8811011238.AA05549@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET
In-Reply-To: ramsdell@linus's message of Thu, 27 Oct 88 14:52:59 EDT <8810271852.AA01520@huxley.sun.uucp>
Subject: Regularization of Procedures in Scheme (pair setters)


   If you set a vector with VECTOR-SET! and a string with STRING-SET!,
   why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
   and CDR-SET!.
   John

My point was that a true regularization of procedure names in Scheme
would require a large number of changes I suspect we are not willing
to make.  I suggest we limit the scope of the regularization effort
and only focus on the non-controversial changes.

John

PS.  The multiple messages problem seems to occur only when a MITRE
mailer tries to directly contact the PSN that is connected to MC, XX,
and Zurich.  MITRE gurus now acknowledge that MITRE machines are
likely involved with the bug, but no one knows why it only occurs with
MIT's PSN.  Thanks to Jonathan help, we are debugging the problem off
line, so this mailing list should see no further multiples messages
from MITRE.

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 28 Oct 88 18:00:04 EDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Oct 88 17:39:35 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Oct 88 17:57:45 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Oct 88 18:01:44 PDT
Received: by joplin.think.com; Fri, 28 Oct 88 17:57:41 EDT
Date: Fri, 28 Oct 88 17:57:41 EDT
From: gls@Think.COM
Message-Id: <8810282157.AA06470@joplin.think.com>
To: jinx@zurich.ai.mit.edu
Cc: ramsdell%linus@mitre-bedford.arpa, mkatz@sesame.stanford.edu,
        rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 27 Oct 88 18:55:52 EDT <8810272255.AA07418@altdorf.ai.mit.edu>
Subject: Regularization of Procedures in Scheme (pair setters)

   Date: Thu, 27 Oct 88 18:55:52 EDT
   From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
   Reply-To: jinx@zurich.ai.mit.edu


       If you set a vector with VECTOR-SET! and a string with STRING-SET!,
       why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
       and CDR-SET!.

   To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
   index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)

Or perhaps the index should be 'CAR or 'CDR:
	(PAIR-SET! foo 'CAR 43)     ;RPLACA       ;-]
--Guy

Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 28 Oct 88 12:12:23 EDT
Received: by DUMBO.AI.MIT.EDU; Fri, 28 Oct 88 12:12:57 edt
Date: Fri, 28 Oct 88 12:12:57 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8810281612.AA07834@dumbo>
To: jinx@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 27 Oct 88 18:55:52 EDT <8810272255.AA07418@altdorf.ai.mit.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
Cc: mkatz@sesame.stanford.edu, rrrs-authors@mc.lcs.mit.edu
Reply-To: arthur@zurich.ai.mit.edu


   Date: Thu, 27 Oct 88 18:55:52 EDT
   From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
   Reply-To: jinx@zurich.ai.mit.edu


       If you set a vector with VECTOR-SET! and a string with STRING-SET!,
       why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
       and CDR-SET!.

   To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
   index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)


In a truly uniform Scheme, there would be no pairs, only vectors! :-))

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Oct 88 07:02:31 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 27 OCT 88 14:36:39 PDT
Date: Thu, 27 Oct 88 14:36:38 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme (pair setters)
In-reply-to: <8810271841.AA01506@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881027-143639-1192@Xerox>

    If you set a vector with VECTOR-SET! and a string with STRING-SET!,
    why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
    and CDR-SET!?
   
Because CAR is not the name of a type.  The correct name would be PAIR-SET!
and for consistency, it must take three arguments: a pair, a field
designator (in this case, perhaps one of the symbols CAR or CDR), and a new
value.  Ecch.

	Pavel

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 23:33:56 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 14:53:14-EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)

If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John

PS. Sorry for the multiple messages last time.  There seemed to be a
mailer problem at MIT.  I think by routing to xx, I can get around it.



Received: from altdorf.ai.mit.edu (TCP 2206400366) by MC.LCS.MIT.EDU 27 Oct 88 21:29:11 EDT
Received: by altdorf.ai.mit.edu (5.59/1.5)
	id AA07418; Thu, 27 Oct 88 18:55:52 EDT
Date: Thu, 27 Oct 88 18:55:52 EDT
From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8810272255.AA07418@altdorf.ai.mit.edu>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: mkatz@sesame.stanford.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 27 Oct 88 14:41:25 EDT <8810271841.AA01506@huxley.sun.uucp>
Subject: Regularization of Procedures in Scheme (pair setters)
Reply-To: jinx@zurich.ai.mit.edu


    If you set a vector with VECTOR-SET! and a string with STRING-SET!,
    why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
    and CDR-SET!.

To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 16:13:32 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 16:12:26-EDT
Full-Name: 
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)

If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John

PS. Sorry for the multiple messages last time.  There seemed to be a
mailer problem at MIT.  I think by routing to xx, I can get around it.



Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 16:12:31 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 16:11:28-EDT
Full-Name: 
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)

If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John

PS. Sorry for the multiple messages last time.  There seemed to be a
mailer problem at MIT.  I think by routing to xx, I can get around it.



Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 27 Oct 88 16:11:44 EDT
Full-Name: 
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA21324; Thu, 27 Oct 88 14:37:42 EDT
Posted-Date: Thu, 27 Oct 88 14:41:25 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA01506; Thu, 27 Oct 88 14:41:25 EDT
Date: Thu, 27 Oct 88 14:41:25 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271841.AA01506@huxley.sun.uucp>
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)

If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John

PS. Sorry for the multiple messages last time.  There seemed to be a
mailer problem at MIT.  I think it has been fixed.

Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 25 Oct 88 11:44:27 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Tue, 25 Oct 88 10:44:18 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: null begin forms 

From Will's minutes:

    F.  Nested begin expressions containing DEFINE forms will be flattened and
    treated as consecutive DEFINE forms, both at top level and at the head of
    lambda bodies.  Macros will be permitted to expand into definitions and
    BEGIN forms containing definitions.

Does this mean that `(begin)' must be, may be, or may not be, allowed?
It would be very nice, say for debugging statement macros that may not
want to generate anything.  That is, I wish a null begin would compile
nothing if it appeared in any but the last place within another
(implicit or explicit) begin.

-- Chris Haynes

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 24 Oct 88 11:40:39 EDT
Received: from sesame.stanford.edu by XX.LCS.MIT.EDU with TCP/SMTP; Mon 24 Oct 88 11:33:43-EDT
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
	id AA14880; Mon, 24 Oct 88 08:32:33 PDT
Date: Mon, 24 Oct 88 08:32:33 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8810241532.AA14880@sesame.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 18 Oct 88 14:26:24 PDT <881018-145647-512@Xerox>
Subject: Regularization of Procedures in Scheme

   Date: Tue, 18 Oct 88 14:26:24 PDT
   From: Pavel.pa@Xerox.COM

   Morry, you ask me to ``See earlier reply to same question'' in response to
   my question about why the long form of APPLY has anything to do with making
   it polymorphic on the final argument.  I didn't see an earlier reply that
   seemed applicable.

Suffice it to say that I misread the documentation on the second form of apply,
whic I never use and the problems are insignificant. 

   Concerning ``polymorphism at two levels'' for the MATCH procedure: Isn't
   all of the polymorphism at the second level contained in the predicate and
   not at all part of MATCH's contract?

I believe that match must step down the elements of its argument comparing the
given value to the first element of each element.  Therefore match is
polymorphic both in the type of the backbone and in the types of the elements
of the backbone.  This is because I was assuming that the predicate would
operate on the given value and the first element of each element of the
backbopne.  I guess an alternative which would only require match to be
polymorphic in the type of the backbone would be for it to take the entire
elements of the backbone as the second argument.  This could actually add an
additional form of flexibility in that match could be specified to return the
value returned by the predicate, when it wasn't #f.  (I actually like this idea
quite a bit.)
					Morry Katz
					katz@polya.stanford.edu

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 24 Oct 88 11:40:39 EDT
Received: from sesame.stanford.edu by XX.LCS.MIT.EDU with TCP/SMTP; Mon 24 Oct 88 11:33:43-EDT
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
	id AA14880; Mon, 24 Oct 88 08:32:33 PDT
Date: Mon, 24 Oct 88 08:32:33 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8810241532.AA14880@sesame.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 18 Oct 88 14:26:24 PDT <881018-145647-512@Xerox>
Subject: Regularization of Procedures in Scheme

   Date: Tue, 18 Oct 88 14:26:24 PDT
   From: Pavel.pa@Xerox.COM

   Morry, you ask me to ``See earlier reply to same question'' in response to
   my question about why the long form of APPLY has anything to do with making
   it polymorphic on the final argument.  I didn't see an earlier reply that
   seemed applicable.

Suffice it to say that I misread the documentation on the second form of apply,
whic I never use and the problems are insignificant. 

   Concerning ``polymorphism at two levels'' for the MATCH procedure: Isn't
   all of the polymorphism at the second level contained in the predicate and
   not at all part of MATCH's contract?

I believe that match must step down the elements of its argument comparing the
given value to the first element of each element.  Therefore match is
polymorphic both in the type of the backbone and in the types of the elements
of the backbone.  This is because I was assuming that the predicate would
operate on the given value and the first element of each element of the
backbopne.  I guess an alternative which would only require match to be
polymorphic in the type of the backbone would be for it to take the entire
elements of the backbone as the second argument.  This could actually add an
additional form of flexibility in that match could be specified to return the
value returned by the predicate, when it wasn't #f.  (I actually like this idea
quite a bit.)
					Morry Katz
					katz@polya.stanford.edu

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Oct 88 18:47:55 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 21 Oct 88 02:50:49-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 20 Oct 88 11:32:04 PDT
Received: by fog.cs.uoregon.edu; Wed, 19 Oct 88 17:04:35 PDT
Date: Wed, 19 Oct 88 17:04:35 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810200004.AA15397@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Regularization of Procedures in Scheme

Another response to Morry's proposal.

But first a response to Pavel:
- I prefer (string #\^ c)
  to (let ((s (make-string 2 #\^))) (string-set! s 1 c) s).
- For reasons of efficiency, I would like to keep gratuitous polymorphism
  out of the standard Scheme procedures.  For example, if VECTOR-REF had
  to work on both vectors and strings, it probably wouldn't be coded
  in-line (as it and STRING-REF are in MacScheme).  Furthermore a type/
  representation inference system probably couldn't infer enough to be
  useful when it saw a use of VECTOR-REF.  And what's the point of giving
  up this efficiency?  It is very rare to know that something is either a
  vector or a string but not to know which, so making VECTOR-REF work on
  both vectors and strings seems gratuitous.
- A hand-coded SUBLIST might be faster (e.g. you could schedule a CAR so
  that a cache miss would result in the load being overlapped with the
  storage allocation for a CONS), but I don't think such arguments should
  determine what goes in the report and what goes in the yellow pages
  since there's nothing to stop implementations from providing custom
  versions of procedures that appear in the yellow pages if they feel
  the custom versions are needed for efficiency.  I'd rather add Chris
  Hanson's 75 or so string procedures to the yellow pages than argue
  about which 5 or so are the most important to add to the report.
  Maybe we should organize part of the yellow pages into auxiliary
  reports for each major data type, with the code as an appendix.

Response to Morry:

- The names of the string-fill! and vector-fill! procedures should include
  an exclamation point.

Non-controversial #1:
  I object to make-list, list-fill!, list-set!, and list-copy on the
  grounds that they are useful only for side-effect-full programming on
  lists, which I claim is an unusual style that the standard should not
  encourage.  The corresponding procedures for strings and vectors are
  less objectionable because side-effect-full programming on strings
  and vectors is normal in Scheme.  The procedures whose absence from
  the report are most noticeable to me are string-set and vector-set
  (without the exclamation marks); these are analogues of cons, used
  for side-effect-free programming with strings and vectors. By the
  way, string-set and vector-set show why e.g. (vector-set! v i e)
  should not be required to return e.  Implementations should be allowed
  to return v for compatibility with vector-set, as MacScheme does.

Controversial #1:
  MacScheme also supplies proper-list?, which returns #f on circular
  lists as well as on lists terminated by something other than the
  empty list.  The syntax-checking pass of the compiler uses it a lot.

Controversial #2:
  I agree with Pavel.  My inclination is not to generalize apply until
  we understand where we're going with optional arguments and such.  The
  connection is that optional arguments are now implemented using rest
  arguments, which are wired in as lists, which end up being the most
  common final argument to apply.  This was probably a mistake, which
  will be hard enough to undo even without further complications.

Controversial #3:
  I oppose b) because there is no particular reason for the result of
  string-map, say, to be a string rather than a vector.  If we're going
  to generalize, let's do it right with c).  I propose, however, that
  someone just post the polymorphic procedures list-map, string-map,
  and vector-map to the yellow pages.  They're trivial to write poorly
  (just convert all the arguments to lists and call map) and probably
  impossible to write efficiently except for special cases.  Similarly
  for the highly polymorphic version of for-each.

Controversial #6:
  I agree with Pavel: these should be in the yellow pages rather than the
  report.  By the way, I think the predicate argument should be the first.

Peace, Will

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 22:55:58 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 21 Oct 88 02:50:25-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 20 Oct 88 03:28:14 PDT
Received: by fog.cs.uoregon.edu; Wed, 19 Oct 88 17:04:35 PDT
Date: Wed, 19 Oct 88 17:04:35 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810200004.AA15397@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Regularization of Procedures in Scheme

Another response to Morry's proposal.

But first a response to Pavel:
- I prefer (string #\^ c)
  to (let ((s (make-string 2 #\^))) (string-set! s 1 c) s).
- For reasons of efficiency, I would like to keep gratuitous polymorphism
  out of the standard Scheme procedures.  For example, if VECTOR-REF had
  to work on both vectors and strings, it probably wouldn't be coded
  in-line (as it and STRING-REF are in MacScheme).  Furthermore a type/
  representation inference system probably couldn't infer enough to be
  useful when it saw a use of VECTOR-REF.  And what's the point of giving
  up this efficiency?  It is very rare to know that something is either a
  vector or a string but not to know which, so making VECTOR-REF work on
  both vectors and strings seems gratuitous.
- A hand-coded SUBLIST might be faster (e.g. you could schedule a CAR so
  that a cache miss would result in the load being overlapped with the
  storage allocation for a CONS), but I don't think such arguments should
  determine what goes in the report and what goes in the yellow pages
  since there's nothing to stop implementations from providing custom
  versions of procedures that appear in the yellow pages if they feel
  the custom versions are needed for efficiency.  I'd rather add Chris
  Hanson's 75 or so string procedures to the yellow pages than argue
  about which 5 or so are the most important to add to the report.
  Maybe we should organize part of the yellow pages into auxiliary
  reports for each major data type, with the code as an appendix.

Response to Morry:

- The names of the string-fill! and vector-fill! procedures should include
  an exclamation point.

Non-controversial #1:
  I object to make-list, list-fill!, list-set!, and list-copy on the
  grounds that they are useful only for side-effect-full programming on
  lists, which I claim is an unusual style that the standard should not
  encourage.  The corresponding procedures for strings and vectors are
  less objectionable because side-effect-full programming on strings
  and vectors is normal in Scheme.  The procedures whose absence from
  the report are most noticeable to me are string-set and vector-set
  (without the exclamation marks); these are analogues of cons, used
  for side-effect-free programming with strings and vectors. By the
  way, string-set and vector-set show why e.g. (vector-set! v i e)
  should not be required to return e.  Implementations should be allowed
  to return v for compatibility with vector-set, as MacScheme does.

Controversial #1:
  MacScheme also supplies proper-list?, which returns #f on circular
  lists as well as on lists terminated by something other than the
  empty list.  The syntax-checking pass of the compiler uses it a lot.

Controversial #2:
  I agree with Pavel.  My inclination is not to generalize apply until
  we understand where we're going with optional arguments and such.  The
  connection is that optional arguments are now implemented using rest
  arguments, which are wired in as lists, which end up being the most
  common final argument to apply.  This was probably a mistake, which
  will be hard enough to undo even without further complications.

Controversial #3:
  I oppose b) because there is no particular reason for the result of
  string-map, say, to be a string rather than a vector.  If we're going
  to generalize, let's do it right with c).  I propose, however, that
  someone just post the polymorphic procedures list-map, string-map,
  and vector-map to the yellow pages.  They're trivial to write poorly
  (just convert all the arguments to lists and call map) and probably
  impossible to write efficiently except for special cases.  Similarly
  for the highly polymorphic version of for-each.

Controversial #6:
  I agree with Pavel: these should be in the yellow pages rather than the
  report.  By the way, I think the predicate argument should be the first.

Peace, Will

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 22:54:50 EDT
Received: from Xerox.COM by XX.LCS.MIT.EDU with TCP/SMTP; Thu 20 Oct 88 23:33:33-EDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 14:56:47 PDT
Date: Tue, 18 Oct 88 14:26:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme
In-reply-to: <8810181537.AA09016@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881018-145647-512@Xerox>

I am convinced by CPH that STRING has its uses.

I don't think that storage efficiency is a valid reason for separating
strings and vectors; Common Lisp implementations manage this just fine.
Remember, the separation could still exist at the implementation level,
invisible to the programmer.  I am, however, willing to drop the issue, now
that I've seen some reasons given (by CPH) for the split.

Morry, you ask me to ``See earlier reply to same question'' in response to
my question about why the long form of APPLY has anything to do with making
it polymorphic on the final argument.  I didn't see an earlier reply that
seemed applicable.

Concerning ``polymorphism at two levels'' for the MATCH procedure: Isn't
all of the polymorphism at the second level contained in the predicate and
not at all part of MATCH's contract?

	Pavel

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 22:47:41 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 18:52:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 18:47:36 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 14:46:56 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 21:01:59 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 18:11:44 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:52:44 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:51:54 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:51:01 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:49:32 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 16:59:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?

I forgot to propose the addition of peek-char for R4RS before
Snowbird.  Is it possible to consider the proposal now?
John

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Oct 88 02:57:07 EDT
Received: from Xerox.COM by XX.LCS.MIT.EDU with TCP/SMTP; Tue 18 Oct 88 01:04:04-EDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 18:51:01 PDT
Date: Mon, 17 Oct 88 18:50:54 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme
In-reply-to: <8810142157.AA06921@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881017-185101-3852@Xerox>

Some notes and responses to Morry's proposal.

- APPEND! is not in R3RS; it was removed after R2RS.

- I'm not sure that I can imagine a reasonable use for STRING.

- Is there some reason why we are trying to keep strings and vectors
separate?  I guess that it makes sense since "foo" would answer #t to
VECTOR? but VECTOR-SET! could not be used to stuff any old Scheme value
into it.  Sigh.  It just seems a bit of a pity.  Perhaps we could make some
(most) of the string/vector operations polymorphic?  That is, strings would
answer #f to VECTOR? but the same procedure could be used to reference
elements of both strings and vectors.  Hmmm.  Comments?

- I guess that I can see why an implementation could make a faster version
of SUBVECTOR that could be written in Scheme (by using a block-transfer
instruction), but I don't see that argument for SUBLIST.  Can someone point
out to me the obviously-faster implementation I'm not seeing?

- The name ``=?'' in Morry's noncontroversial #6 should be ``equal?''.

- Controversial#1: Cedar Scheme has a predicate ``proper-list?'' that does
what Morry's ``list?'' would do.  It's there because I've found it useful
at times, for example in the parsing of lambda-lists.

- Controversial #2: I don't see why the existence of the second form of
APPLY has any bearing on the question of whether or not vectors and strings
can be passed as the final argument.

- Controversial #3: For option (c), I think it's probably too expensive to
have to make a first pass down a list passed as an argument in order to
know how big a string/vector to allocate for the result.  Maybe I'm just a
worry-wart, though.  Option (c) is certainly more flexible.  On the other
hand, these can be easily written in Scheme (I think as efficiently as in
some lower-level language), so I don't perceive a burning need for them.

- Controversials #4, 5, and 6: Since I don't think that EQUAL? is a
particularly natural predicate to have in the language (that is, it doesn't
seem as natural a predicate as EQ? and EQV?, it's just an arbitrary choice
out of the space of equivalence relations that happens to find some use),
I've never felt that MEMBER and ASSOC were particularly worthy of special
treatment.  I would perhaps prefer that these names be used for more
general operations that took an equivalence predicate as an argument.  This
aside, though, I agree with Morry that no extension is desirable here.  As
for #6, I don't understand why Morry says that ``For match, this
polymorphism would extend to 2 levels into the data structure'' since MATCH
doesn't seem to care about a second level.  More useful than MEMBER? and
MATCH might be the Common Lisp sequence functions POSITION and FIND which
take a value, a predicate, and a sequence and return, respectively, the
index and the value of the first element of the sequence on which (pred
value element) returns true.  The function POSITION can be used as a
predicate, just like MEMBER?.  Again, though, as in #3, I don't see why
these functions should be in the report at all, since they're so easy to
write.  Put them in the yellow pages...

	Pavel

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Oct 88 02:56:59 EDT
Received: from Xerox.COM by XX.LCS.MIT.EDU with TCP/SMTP; Tue 18 Oct 88 01:03:59-EDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 17:40:08 PDT
Date: Mon, 17 Oct 88 17:39:50 PDT
From: Pavel.pa@Xerox.COM
Subject: (NOT '())?
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <881017-174008-3761@Xerox>

I couldn't tell from Will's summary of the R4RS meeting at Snowbird what
had been resolved concerning the value of (NOT '()).  Will had proposed
that it be made unspecified in the next revision of the report.  Was this
passed?

	Pavel

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Oct 88 19:30:40 EDT
Received: from sesame.stanford.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 14 Oct 88 17:59:25-EDT
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
	id AA06921; Fri, 14 Oct 88 14:57:24 PDT
Date: Fri, 14 Oct 88 14:57:24 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8810142157.AA06921@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Regularization of Procedures in Scheme

For those of you who don't remember, I was assigned the task at L&FP to
regularize the procedures involving lists, strings, and vectors for R4RS.
Initially, this looked like a trivial, Noncontroversial task; but, it turns out
that there are actually some important semantic issues to be discussed.  I have
therefore decided to pass my ideas before the entire community, rather than
just sending them straight to the editors.  

I will begin this discussion with what I believe are the Noncontroversial
changes and then proceed to the Controversial ones.  In order to better
understand the issues I have included the chart below which enumerates the
relevant procedures currently in R3RS.

LIST                STRING              VECTOR
----                ------              ------
list                                    vector
                    make-string         make-vector
                    string-fill         vector-fill
list-ref            string-ref          vector-ref
                    string-set!         vector-set!
                    string-copy
length              string-length       vector-length
append              string-append
append!
list->string        string->list        vector->list
list->vector
reverse
                    substring
                    string=?
                    string?             vector?
apply
map, foreach
memq, memv, member
assq, assv, assoc

Noncontroversial:
1)  Add string, make-list, list-fill, list-set!, list-copy, vector-copy,
    vector-append, string->vector, and vector->string with the obvious
    semantics. 
2)  Create aliases list-length and list-append for length and append,
    respectively. 
3)  Append! should NOT be generalized since most implementations (for good
    reasons) represent strings and vectors in a manner that is incompatible
    with append! semantics.
4)  Reverse should NOT be generalized since the extensions would be pretty much
    useless.  
5)  Sublist and subvector should be added because they are potentially useful
    and the implementations in scheme are much less efficient than ones which
    could be supplied by an implementor.
6)  String=? is only present for symetry with string-ci=? and should NOT be
    generalized to list=? and vector=? since we already have =?.

Controversial:
1)  Create list? which checks for a null terminated list.  This CAN be written
    by a user and is only marginally useful, but I believe it is important that
    it exist for symetry reasons.
2)  If we keep both syntaxes for apply
       (apply proc args)
       (apply proc arg1 arg2 ...  args)
    then this can't be generalized.  However, I believe that we should restrict
    ourselves to the first syntax ONLY.  Then args could be any of a list,
    string, or vector whose elements would be spread before the actual
    application was performed.

3)  There are several possibilities for map and foreach:
    a)  Status quo
    b)  Introduce list-map, string-map, vector-map, list-foreach,
        string-foreach, and vector-foreach.  List-map and list-foreach would be
        identical to the current map and foreach, respectively. The others
        would have the following syntaxes and semantics
    	    (string-map proc string1 string2 ...)
	    (vector-map proc vector1 vector2 ...)
   	    (string-foreach proc string1 string2 ...)
	    (vector-foreach proc vector1 vector2 ...)
	The string version would take strings as arguments and in the case of
        string-map would return a string.  The vector versions would do
        similarly.  It would be a type error to pass a string to list-map, a
        list to vector-map, etc.
    c)  The same 6 procedures would be introduced as in b).  In this case the
        name would specify the type of the return value.  The procedures would
        be polymorphic over arguments of type list, string, and vector.  All
        that would be required would be that the arguments all have the same
        length. 
    I am personally in favor of either b) or c).  I like the semantics of c),
    but realize that some implementors may find its semantics objectionable.
4)  Memq, memv, and member are quite problematic.  They could be extended to
    allow the second argument to be a vector in the obvious way, but then what
    should they return on a match.  Returning a subvector is unsatisfactory
    because the aliasing one gets with a sublist would undoubtedly not be
    present for a subvector, and thus the original structure could not be
    modified based on the result.  In my experience, this is one of the most
    common uses for these procedures and it would be negated.  Another
    alternative is just to return #t and #f.  However, these seems to be
    unintuitively incompatible with the original versions.  Extensions for
    strings are even worse, because the equivalence distinctions between eq,
    eqv, and equal are not present and have instead been replaced by case
    sensativity and insensitivity.  MY RECOMMENDATION IS TO MAKE NO EXTENSION.
5)  Any extensions to assq, assv, and assoc have similar problems to those of
    memq, etc. and I therefore again RECOMMEND NO EXTENSION.
6)  As a result of 5) and 6), I suggest adding two new families of procedures
    which for the sake of exposition I will call member? and match.  (I know
    these are horrible names, but if people like the idea, we'll worry about
    what to call them later.)  Their syntaxes would be as follows:
       (list-member? val pred list)
       (string-member? val pred string)
       (vector-member? val pred vector)
       (list-match val pred list)
       (string-match val pred string)
       (vector-match val pred string)
    The member procedures would return #f if (pred val (foo-ref foo i))
    returned #f for all i, where foo is either list, string, or vector.
    Otherwise, they would return #t.  The match procedures would perform
    similarly except that they would the first element for which pred returned
    #t, #f otherwise.  A decision would have to be made for match as to whether
    each element of a vector would have to itself be a vector.  Obviously, for
    strings each element would have to be a character and so this version would
    be somewhat useless.  
    As A RESULT, I propose that instead we introduce just the procedures
    member? and match which are polymorphic over all the reasonable types
    (i.e., strings, vectors, and lists).  For match, this polymorphism would
    extend to 2 levels into the data structure.

    					Morry Katz
					katz@polya.stanford.edu

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 22:28:21 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:59:15-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 14:19:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting

At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird.  The report has
three parts: 

  1.  a summary of changes to the R3RS that will be made in the R4RS
  2.  a review of the things that still need to be done for R4RS
  3.  the action taken on each agenda proposal, with a summary of the debate

Hal Abelson chaired the meeting and did a very fine job.  About fifty people
attended.

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

PART 1.  Changes that will appear in the R4RS.

These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988.  Changes that did not appear in that
list are identified by letters rather than numbers.

1.1.  Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.

1.2.  The sets defined by the following predicates will be required to be
disjoint:  boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.

1.3.  The variables NIL and T will be removed from the Report.

1.5, 1.6, 1.7, 1.8.  Certain sentences will be clarified.

1.10, 1.11, 1.12.  The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp.  Changes include:
  The radix prefix will precede the sign, eg #x-ab.
  The exactness prefix will precede the sign, eg #i-3.
  Exponents will be illegal in rational syntax.
  Exponents will be illegal unless the radix is 10.
  The precision prefix is to be replaced by exponent markers as in Common Lisp,
    eg 1S3, 1F3, 1D3, 1L3, 1E3.
  Any constant with an imaginary part will be required to have an explicit sign
    in front of the imaginary part.  The formal syntax, to be written by
    Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.

1.13.  A numeric constant will be considered exact unless it contains one of
the following:
  #i                  explicit inexactness prefix
  @                   polar notation
  .                   an explicit decimal point
  #                   imprecise digits
  e                   exponent marker
  s                   exponent marker
  f                   exponent marker
  d                   exponent marker
  l                   exponent marker

1.14.  The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.

1.15.  RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.

A.  The branch cuts for ATAN will be corrected to be whatever Steele says.

B.  INTEGER->CHAR will require an exact integer argument.

C.  APPROXIMATE will disappear.  The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations.  The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=.  The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.

2.1.  The following syntaxes and procedures become essential:

    CASE, AND, OR, QUASIQUOTE
    APPEND with zero or more arguments
    REVERSE
    MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
    + and * with zero or more arguments
    - and / with one argument
    some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
    CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
    CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
    CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
    MAKE-STRING (with one or two arguments)
    STRING-SET!
    STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
      (two arguments only)
    STRING-APPEND
    MAP and FOR-EACH with two or more arguments
    OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT

LAST-PAIR will disappear from the report.

[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:

    (if E0 E1)
    (let* ...)
    (do ...)
    named let
    internal definitions
    delay
    list-tail
    list-ref
    - and / with more than two arguments
    string-copy, string-fill!
    vector-fill!
    apply with more than two arguments
    force
    with-input-from-file, with-output-to-file
    char-ready?
    transcript-on, transcript-off

The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]

D.  A section on immutable structures will be added.  Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure.  Data structures that appear as constants will be immutable.
[Note:  This is merely a clarification.  See the last sentence of section
4.1.2 in R3RS.]

E.  Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.

F.  Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies.  Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.

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

PART 2.  Things that still need to be done for R4RS.

1.10, 1.11, 1.12.  Formal syntax of numeric constants: Clinger.

1.15.  Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.

A.  Decide on branch cuts for ATAN: Steele.

3.1.  Propose macro facility: Bawden, Rees, Dybvig, Heib.

If the macro committee gets stuck, R4RS will go forward without macros.

Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details.  New
proposals were solicited.  If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.

1.4.  Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.

2.2.  Propose regularization of procedures: Katz.

4.4.  Propose a better name for named let: anyone.

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

PART 3.  Action taken on each agenda proposal.

1.1.  Reserved words and portable code.  Adopted by acclamation.  Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.

1.2.  Disjointness of types.  Adopted by acclamation.  Two people objected
to requiring (NOT (EQ? #F '())).  Promises and ports were considered but were
not added to the list of disjoint types.

1.3.  Eliminate NIL, T.  Adopted by acclamation.

1.4.  EQV?  Not adopted.  Reasons: The body of the Report should not refer to
the formal semantics.  If the body is not precise enough to stand on its own,
it should be made more precise.  Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures.  Sentences should be
collapsed wherever possible.  The disjointness of types creates some changes
and should simplify the discussion.

1.5.  Change wording of LETREC restriction.  Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>.  If this restriction is violated, then it is an
error."

1.6.  Clarify wording of LETREC.  Adopted by acclamation without debate.

1.7.  Clarify status of CI.  Adopted by acclamation without debate.

1.8.  Clarify the specification of TRUNCATE.  Adopted by acclamation without
debate.

1.9.  Improve the discussion of exactness and inexactness.  Not debated per se.
See C.

1.10.  Change the syntax of numbers.  The syntax of complex numbers occasioned
much debate, with the result summarized in part 1.  The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12.  Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.

1.11.  Clarify the status of exponents.  Adopted by acclamation.  It was noted
that the grammar would be clearer if <digit> were <digit 10>.

1.12.  Exponents illegal in fractions.  Adopted by acclamation.

1.13.  Exactness and inexactness of constants.  Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.

1.14.  Make duplicated formals illegal.  Adopted by acclamation.  Debate
clarified that "illegal" should mean "is an error".

1.15.  Clarify semantics of RATIONALIZE.  Adopted by acclamation.  Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving.  [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]

A.  Branch cuts for ATAN.  Adopted by acclamation.  The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL.  Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.

B.  Require exact argument for INTEGER->CHAR.  Adopted by acclamation.

C.  Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER.  Questions about the semantics of these
procedures persist.  By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them.  Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.

2.1.  Flush inessential features.  For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential.  The unanimous decisions were listed in part 1.  The
only inessential feature that everyone wanted to flush was LAST-PAIR.

D.  Add section on immutable structures.  Adopted by acclamation.  This
issue arose during debate on making STRING-SET! essential.

2.2.  Make procedures more regular.  Not debated very much.  Katz volunteered
to develop a concrete proposal.

2.3.  Underspecification.  The value returned by SET! was discussed as an
example.  There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified.  No consensus but
probably a useful debate.

3.1.  Macros.  Pre-adopted by acclamation.  That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb.  Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.

3.2.  Modules.  Not adopted.
3.3.  Replace LOAD with INCLUDE.  Not adopted.
3.4.  First class environments.  Not adopted.
3.5.  Add EVAL.  Not adopted.
3.6.  Add second argument to LOAD.  Not adopted.

F.  Flatten BEGIN forms containing definitions.  Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE.  It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.

3.7.  Add LAMBDA*.  Not adopted.  The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.

3.8.  Multiple return values.  Not adopted.  Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally.  A secondary issue concerned whether extra return
values should be ignored or an error.  We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private.  Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.

3.9.  Optional arguments.  Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.

3.10.  Record types.  Not adopted.  Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.

At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make.  There was not much time for debate.

3.11.  Add TYPE-OF.  Not adopted.  Noted: a predicate TYPE? would be
more in the spirit of Scheme.

4.20.  Change the specification of AND.  Not adopted.  This proposal
was incorrect in the list of proposals that was sent out.  [My fault
-- Clinger]  It should have been:  "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.

4.4  Eliminate named let.  Most people seemed willing to change the
name of named let.  RECUR was suggested but objected to.  It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS.  [So far a number of names have been nominated
but none have been agreed upon.]

4.24.  Rename CHAR-READY? to READ-CHAR-READY?  Not adopted.

4.5.  Eliminate =>.  Not adopted.

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 22:27:16 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:57:05-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:10:21 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting

At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird.  The report has
three parts: 

  1.  a summary of changes to the R3RS that will be made in the R4RS
  2.  a review of the things that still need to be done for R4RS
  3.  the action taken on each agenda proposal, with a summary of the debate

Hal Abelson chaired the meeting and did a very fine job.  About fifty people
attended.

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

PART 1.  Changes that will appear in the R4RS.

These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988.  Changes that did not appear in that
list are identified by letters rather than numbers.

1.1.  Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.

1.2.  The sets defined by the following predicates will be required to be
disjoint:  boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.

1.3.  The variables NIL and T will be removed from the Report.

1.5, 1.6, 1.7, 1.8.  Certain sentences will be clarified.

1.10, 1.11, 1.12.  The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp.  Changes include:
  The radix prefix will precede the sign, eg #x-ab.
  The exactness prefix will precede the sign, eg #i-3.
  Exponents will be illegal in rational syntax.
  Exponents will be illegal unless the radix is 10.
  The precision prefix is to be replaced by exponent markers as in Common Lisp,
    eg 1S3, 1F3, 1D3, 1L3, 1E3.
  Any constant with an imaginary part will be required to have an explicit sign
    in front of the imaginary part.  The formal syntax, to be written by
    Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.

1.13.  A numeric constant will be considered exact unless it contains one of
the following:
  #i                  explicit inexactness prefix
  @                   polar notation
  .                   an explicit decimal point
  #                   imprecise digits
  e                   exponent marker
  s                   exponent marker
  f                   exponent marker
  d                   exponent marker
  l                   exponent marker

1.14.  The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.

1.15.  RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.

A.  The branch cuts for ATAN will be corrected to be whatever Steele says.

B.  INTEGER->CHAR will require an exact integer argument.

C.  APPROXIMATE will disappear.  The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations.  The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=.  The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.

2.1.  The following syntaxes and procedures become essential:

    CASE, AND, OR, QUASIQUOTE
    APPEND with zero or more arguments
    REVERSE
    MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
    + and * with zero or more arguments
    - and / with one argument
    some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
    CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
    CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
    CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
    MAKE-STRING (with one or two arguments)
    STRING-SET!
    STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
      (two arguments only)
    STRING-APPEND
    MAP and FOR-EACH with two or more arguments
    OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT

LAST-PAIR will disappear from the report.

[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:

    (if E0 E1)
    (let* ...)
    (do ...)
    named let
    internal definitions
    delay
    list-tail
    list-ref
    - and / with more than two arguments
    string-copy, string-fill!
    vector-fill!
    apply with more than two arguments
    force
    with-input-from-file, with-output-to-file
    char-ready?
    transcript-on, transcript-off

The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]

D.  A section on immutable structures will be added.  Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure.  Data structures that appear as constants will be immutable.
[Note:  This is merely a clarification.  See the last sentence of section
4.1.2 in R3RS.]

E.  Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.

F.  Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies.  Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.

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

PART 2.  Things that still need to be done for R4RS.

1.10, 1.11, 1.12.  Formal syntax of numeric constants: Clinger.

1.15.  Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.

A.  Decide on branch cuts for ATAN: Steele.

3.1.  Propose macro facility: Bawden, Rees, Dybvig, Heib.

If the macro committee gets stuck, R4RS will go forward without macros.

Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details.  New
proposals were solicited.  If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.

1.4.  Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.

2.2.  Propose regularization of procedures: Katz.

4.4.  Propose a better name for named let: anyone.

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

PART 3.  Action taken on each agenda proposal.

1.1.  Reserved words and portable code.  Adopted by acclamation.  Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.

1.2.  Disjointness of types.  Adopted by acclamation.  Two people objected
to requiring (NOT (EQ? #F '())).  Promises and ports were considered but were
not added to the list of disjoint types.

1.3.  Eliminate NIL, T.  Adopted by acclamation.

1.4.  EQV?  Not adopted.  Reasons: The body of the Report should not refer to
the formal semantics.  If the body is not precise enough to stand on its own,
it should be made more precise.  Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures.  Sentences should be
collapsed wherever possible.  The disjointness of types creates some changes
and should simplify the discussion.

1.5.  Change wording of LETREC restriction.  Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>.  If this restriction is violated, then it is an
error."

1.6.  Clarify wording of LETREC.  Adopted by acclamation without debate.

1.7.  Clarify status of CI.  Adopted by acclamation without debate.

1.8.  Clarify the specification of TRUNCATE.  Adopted by acclamation without
debate.

1.9.  Improve the discussion of exactness and inexactness.  Not debated per se.
See C.

1.10.  Change the syntax of numbers.  The syntax of complex numbers occasioned
much debate, with the result summarized in part 1.  The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12.  Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.

1.11.  Clarify the status of exponents.  Adopted by acclamation.  It was noted
that the grammar would be clearer if <digit> were <digit 10>.

1.12.  Exponents illegal in fractions.  Adopted by acclamation.

1.13.  Exactness and inexactness of constants.  Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.

1.14.  Make duplicated formals illegal.  Adopted by acclamation.  Debate
clarified that "illegal" should mean "is an error".

1.15.  Clarify semantics of RATIONALIZE.  Adopted by acclamation.  Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving.  [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]

A.  Branch cuts for ATAN.  Adopted by acclamation.  The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL.  Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.

B.  Require exact argument for INTEGER->CHAR.  Adopted by acclamation.

C.  Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER.  Questions about the semantics of these
procedures persist.  By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them.  Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.

2.1.  Flush inessential features.  For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential.  The unanimous decisions were listed in part 1.  The
only inessential feature that everyone wanted to flush was LAST-PAIR.

D.  Add section on immutable structures.  Adopted by acclamation.  This
issue arose during debate on making STRING-SET! essential.

2.2.  Make procedures more regular.  Not debated very much.  Katz volunteered
to develop a concrete proposal.

2.3.  Underspecification.  The value returned by SET! was discussed as an
example.  There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified.  No consensus but
probably a useful debate.

3.1.  Macros.  Pre-adopted by acclamation.  That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb.  Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.

3.2.  Modules.  Not adopted.
3.3.  Replace LOAD with INCLUDE.  Not adopted.
3.4.  First class environments.  Not adopted.
3.5.  Add EVAL.  Not adopted.
3.6.  Add second argument to LOAD.  Not adopted.

F.  Flatten BEGIN forms containing definitions.  Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE.  It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.

3.7.  Add LAMBDA*.  Not adopted.  The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.

3.8.  Multiple return values.  Not adopted.  Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally.  A secondary issue concerned whether extra return
values should be ignored or an error.  We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private.  Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.

3.9.  Optional arguments.  Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.

3.10.  Record types.  Not adopted.  Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.

At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make.  There was not much time for debate.

3.11.  Add TYPE-OF.  Not adopted.  Noted: a predicate TYPE? would be
more in the spirit of Scheme.

4.20.  Change the specification of AND.  Not adopted.  This proposal
was incorrect in the list of proposals that was sent out.  [My fault
-- Clinger]  It should have been:  "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.

4.4  Eliminate named let.  Most people seemed willing to change the
name of named let.  RECUR was suggested but objected to.  It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS.  [So far a number of names have been nominated
but none have been agreed upon.]

4.24.  Rename CHAR-READY? to READ-CHAR-READY?  Not adopted.

4.5.  Eliminate =>.  Not adopted.

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 20:55:30 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:57:52-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:19:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting

At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird.  The report has
three parts: 

  1.  a summary of changes to the R3RS that will be made in the R4RS
  2.  a review of the things that still need to be done for R4RS
  3.  the action taken on each agenda proposal, with a summary of the debate

Hal Abelson chaired the meeting and did a very fine job.  About fifty people
attended.

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

PART 1.  Changes that will appear in the R4RS.

These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988.  Changes that did not appear in that
list are identified by letters rather than numbers.

1.1.  Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.

1.2.  The sets defined by the following predicates will be required to be
disjoint:  boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.

1.3.  The variables NIL and T will be removed from the Report.

1.5, 1.6, 1.7, 1.8.  Certain sentences will be clarified.

1.10, 1.11, 1.12.  The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp.  Changes include:
  The radix prefix will precede the sign, eg #x-ab.
  The exactness prefix will precede the sign, eg #i-3.
  Exponents will be illegal in rational syntax.
  Exponents will be illegal unless the radix is 10.
  The precision prefix is to be replaced by exponent markers as in Common Lisp,
    eg 1S3, 1F3, 1D3, 1L3, 1E3.
  Any constant with an imaginary part will be required to have an explicit sign
    in front of the imaginary part.  The formal syntax, to be written by
    Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.

1.13.  A numeric constant will be considered exact unless it contains one of
the following:
  #i                  explicit inexactness prefix
  @                   polar notation
  .                   an explicit decimal point
  #                   imprecise digits
  e                   exponent marker
  s                   exponent marker
  f                   exponent marker
  d                   exponent marker
  l                   exponent marker

1.14.  The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.

1.15.  RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.

A.  The branch cuts for ATAN will be corrected to be whatever Steele says.

B.  INTEGER->CHAR will require an exact integer argument.

C.  APPROXIMATE will disappear.  The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations.  The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=.  The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.

2.1.  The following syntaxes and procedures become essential:

    CASE, AND, OR, QUASIQUOTE
    APPEND with zero or more arguments
    REVERSE
    MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
    + and * with zero or more arguments
    - and / with one argument
    some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
    CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
    CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
    CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
    MAKE-STRING (with one or two arguments)
    STRING-SET!
    STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
      (two arguments only)
    STRING-APPEND
    MAP and FOR-EACH with two or more arguments
    OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT

LAST-PAIR will disappear from the report.

[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:

    (if E0 E1)
    (let* ...)
    (do ...)
    named let
    internal definitions
    delay
    list-tail
    list-ref
    - and / with more than two arguments
    string-copy, string-fill!
    vector-fill!
    apply with more than two arguments
    force
    with-input-from-file, with-output-to-file
    char-ready?
    transcript-on, transcript-off

The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]

D.  A section on immutable structures will be added.  Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure.  Data structures that appear as constants will be immutable.
[Note:  This is merely a clarification.  See the last sentence of section
4.1.2 in R3RS.]

E.  Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.

F.  Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies.  Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.

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

PART 2.  Things that still need to be done for R4RS.

1.10, 1.11, 1.12.  Formal syntax of numeric constants: Clinger.

1.15.  Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.

A.  Decide on branch cuts for ATAN: Steele.

3.1.  Propose macro facility: Bawden, Rees, Dybvig, Heib.

If the macro committee gets stuck, R4RS will go forward without macros.

Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details.  New
proposals were solicited.  If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.

1.4.  Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.

2.2.  Propose regularization of procedures: Katz.

4.4.  Propose a better name for named let: anyone.

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

PART 3.  Action taken on each agenda proposal.

1.1.  Reserved words and portable code.  Adopted by acclamation.  Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.

1.2.  Disjointness of types.  Adopted by acclamation.  Two people objected
to requiring (NOT (EQ? #F '())).  Promises and ports were considered but were
not added to the list of disjoint types.

1.3.  Eliminate NIL, T.  Adopted by acclamation.

1.4.  EQV?  Not adopted.  Reasons: The body of the Report should not refer to
the formal semantics.  If the body is not precise enough to stand on its own,
it should be made more precise.  Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures.  Sentences should be
collapsed wherever possible.  The disjointness of types creates some changes
and should simplify the discussion.

1.5.  Change wording of LETREC restriction.  Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>.  If this restriction is violated, then it is an
error."

1.6.  Clarify wording of LETREC.  Adopted by acclamation without debate.

1.7.  Clarify status of CI.  Adopted by acclamation without debate.

1.8.  Clarify the specification of TRUNCATE.  Adopted by acclamation without
debate.

1.9.  Improve the discussion of exactness and inexactness.  Not debated per se.
See C.

1.10.  Change the syntax of numbers.  The syntax of complex numbers occasioned
much debate, with the result summarized in part 1.  The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12.  Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.

1.11.  Clarify the status of exponents.  Adopted by acclamation.  It was noted
that the grammar would be clearer if <digit> were <digit 10>.

1.12.  Exponents illegal in fractions.  Adopted by acclamation.

1.13.  Exactness and inexactness of constants.  Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.

1.14.  Make duplicated formals illegal.  Adopted by acclamation.  Debate
clarified that "illegal" should mean "is an error".

1.15.  Clarify semantics of RATIONALIZE.  Adopted by acclamation.  Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving.  [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]

A.  Branch cuts for ATAN.  Adopted by acclamation.  The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL.  Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.

B.  Require exact argument for INTEGER->CHAR.  Adopted by acclamation.

C.  Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER.  Questions about the semantics of these
procedures persist.  By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them.  Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.

2.1.  Flush inessential features.  For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential.  The unanimous decisions were listed in part 1.  The
only inessential feature that everyone wanted to flush was LAST-PAIR.

D.  Add section on immutable structures.  Adopted by acclamation.  This
issue arose during debate on making STRING-SET! essential.

2.2.  Make procedures more regular.  Not debated very much.  Katz volunteered
to develop a concrete proposal.

2.3.  Underspecification.  The value returned by SET! was discussed as an
example.  There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified.  No consensus but
probably a useful debate.

3.1.  Macros.  Pre-adopted by acclamation.  That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb.  Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.

3.2.  Modules.  Not adopted.
3.3.  Replace LOAD with INCLUDE.  Not adopted.
3.4.  First class environments.  Not adopted.
3.5.  Add EVAL.  Not adopted.
3.6.  Add second argument to LOAD.  Not adopted.

F.  Flatten BEGIN forms containing definitions.  Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE.  It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.

3.7.  Add LAMBDA*.  Not adopted.  The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.

3.8.  Multiple return values.  Not adopted.  Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally.  A secondary issue concerned whether extra return
values should be ignored or an error.  We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private.  Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.

3.9.  Optional arguments.  Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.

3.10.  Record types.  Not adopted.  Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.

At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make.  There was not much time for debate.

3.11.  Add TYPE-OF.  Not adopted.  Noted: a predicate TYPE? would be
more in the spirit of Scheme.

4.20.  Change the specification of AND.  Not adopted.  This proposal
was incorrect in the list of proposals that was sent out.  [My fault
-- Clinger]  It should have been:  "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.

4.4  Eliminate named let.  Most people seemed willing to change the
name of named let.  RECUR was suggested but objected to.  It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS.  [So far a number of names have been nominated
but none have been agreed upon.]

4.24.  Rename CHAR-READY? to READ-CHAR-READY?  Not adopted.

4.5.  Eliminate =>.  Not adopted.

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 19:54:10 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:58:29-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:49:36 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting

At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird.  The report has
three parts: 

  1.  a summary of changes to the R3RS that will be made in the R4RS
  2.  a review of the things that still need to be done for R4RS
  3.  the action taken on each agenda proposal, with a summary of the debate

Hal Abelson chaired the meeting and did a very fine job.  About fifty people
attended.

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

PART 1.  Changes that will appear in the R4RS.

These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988.  Changes that did not appear in that
list are identified by letters rather than numbers.

1.1.  Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.

1.2.  The sets defined by the following predicates will be required to be
disjoint:  boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.

1.3.  The variables NIL and T will be removed from the Report.

1.5, 1.6, 1.7, 1.8.  Certain sentences will be clarified.

1.10, 1.11, 1.12.  The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp.  Changes include:
  The radix prefix will precede the sign, eg #x-ab.
  The exactness prefix will precede the sign, eg #i-3.
  Exponents will be illegal in rational syntax.
  Exponents will be illegal unless the radix is 10.
  The precision prefix is to be replaced by exponent markers as in Common Lisp,
    eg 1S3, 1F3, 1D3, 1L3, 1E3.
  Any constant with an imaginary part will be required to have an explicit sign
    in front of the imaginary part.  The formal syntax, to be written by
    Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.

1.13.  A numeric constant will be considered exact unless it contains one of
the following:
  #i                  explicit inexactness prefix
  @                   polar notation
  .                   an explicit decimal point
  #                   imprecise digits
  e                   exponent marker
  s                   exponent marker
  f                   exponent marker
  d                   exponent marker
  l                   exponent marker

1.14.  The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.

1.15.  RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.

A.  The branch cuts for ATAN will be corrected to be whatever Steele says.

B.  INTEGER->CHAR will require an exact integer argument.

C.  APPROXIMATE will disappear.  The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations.  The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=.  The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.

2.1.  The following syntaxes and procedures become essential:

    CASE, AND, OR, QUASIQUOTE
    APPEND with zero or more arguments
    REVERSE
    MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
    + and * with zero or more arguments
    - and / with one argument
    some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
    CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
    CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
    CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
    MAKE-STRING (with one or two arguments)
    STRING-SET!
    STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
      (two arguments only)
    STRING-APPEND
    MAP and FOR-EACH with two or more arguments
    OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT

LAST-PAIR will disappear from the report.

[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:

    (if E0 E1)
    (let* ...)
    (do ...)
    named let
    internal definitions
    delay
    list-tail
    list-ref
    - and / with more than two arguments
    string-copy, string-fill!
    vector-fill!
    apply with more than two arguments
    force
    with-input-from-file, with-output-to-file
    char-ready?
    transcript-on, transcript-off

The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]

D.  A section on immutable structures will be added.  Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure.  Data structures that appear as constants will be immutable.
[Note:  This is merely a clarification.  See the last sentence of section
4.1.2 in R3RS.]

E.  Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.

F.  Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies.  Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.

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

PART 2.  Things that still need to be done for R4RS.

1.10, 1.11, 1.12.  Formal syntax of numeric constants: Clinger.

1.15.  Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.

A.  Decide on branch cuts for ATAN: Steele.

3.1.  Propose macro facility: Bawden, Rees, Dybvig, Heib.

If the macro committee gets stuck, R4RS will go forward without macros.

Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details.  New
proposals were solicited.  If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.

1.4.  Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.

2.2.  Propose regularization of procedures: Katz.

4.4.  Propose a better name for named let: anyone.

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

PART 3.  Action taken on each agenda proposal.

1.1.  Reserved words and portable code.  Adopted by acclamation.  Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.

1.2.  Disjointness of types.  Adopted by acclamation.  Two people objected
to requiring (NOT (EQ? #F '())).  Promises and ports were considered but were
not added to the list of disjoint types.

1.3.  Eliminate NIL, T.  Adopted by acclamation.

1.4.  EQV?  Not adopted.  Reasons: The body of the Report should not refer to
the formal semantics.  If the body is not precise enough to stand on its own,
it should be made more precise.  Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures.  Sentences should be
collapsed wherever possible.  The disjointness of types creates some changes
and should simplify the discussion.

1.5.  Change wording of LETREC restriction.  Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>.  If this restriction is violated, then it is an
error."

1.6.  Clarify wording of LETREC.  Adopted by acclamation without debate.

1.7.  Clarify status of CI.  Adopted by acclamation without debate.

1.8.  Clarify the specification of TRUNCATE.  Adopted by acclamation without
debate.

1.9.  Improve the discussion of exactness and inexactness.  Not debated per se.
See C.

1.10.  Change the syntax of numbers.  The syntax of complex numbers occasioned
much debate, with the result summarized in part 1.  The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12.  Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.

1.11.  Clarify the status of exponents.  Adopted by acclamation.  It was noted
that the grammar would be clearer if <digit> were <digit 10>.

1.12.  Exponents illegal in fractions.  Adopted by acclamation.

1.13.  Exactness and inexactness of constants.  Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.

1.14.  Make duplicated formals illegal.  Adopted by acclamation.  Debate
clarified that "illegal" should mean "is an error".

1.15.  Clarify semantics of RATIONALIZE.  Adopted by acclamation.  Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving.  [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]

A.  Branch cuts for ATAN.  Adopted by acclamation.  The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL.  Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.

B.  Require exact argument for INTEGER->CHAR.  Adopted by acclamation.

C.  Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER.  Questions about the semantics of these
procedures persist.  By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them.  Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.

2.1.  Flush inessential features.  For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential.  The unanimous decisions were listed in part 1.  The
only inessential feature that everyone wanted to flush was LAST-PAIR.

D.  Add section on immutable structures.  Adopted by acclamation.  This
issue arose during debate on making STRING-SET! essential.

2.2.  Make procedures more regular.  Not debated very much.  Katz volunteered
to develop a concrete proposal.

2.3.  Underspecification.  The value returned by SET! was discussed as an
example.  There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified.  No consensus but
probably a useful debate.

3.1.  Macros.  Pre-adopted by acclamation.  That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb.  Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.

3.2.  Modules.  Not adopted.
3.3.  Replace LOAD with INCLUDE.  Not adopted.
3.4.  First class environments.  Not adopted.
3.5.  Add EVAL.  Not adopted.
3.6.  Add second argument to LOAD.  Not adopted.

F.  Flatten BEGIN forms containing definitions.  Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE.  It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.

3.7.  Add LAMBDA*.  Not adopted.  The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.

3.8.  Multiple return values.  Not adopted.  Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally.  A secondary issue concerned whether extra return
values should be ignored or an error.  We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private.  Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.

3.9.  Optional arguments.  Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.

3.10.  Record types.  Not adopted.  Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.

At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make.  There was not much time for debate.

3.11.  Add TYPE-OF.  Not adopted.  Noted: a predicate TYPE? would be
more in the spirit of Scheme.

4.20.  Change the specification of AND.  Not adopted.  This proposal
was incorrect in the list of proposals that was sent out.  [My fault
-- Clinger]  It should have been:  "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.

4.4  Eliminate named let.  Most people seemed willing to change the
name of named let.  RECUR was suggested but objected to.  It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS.  [So far a number of names have been nominated
but none have been agreed upon.]

4.24.  Rename CHAR-READY? to READ-CHAR-READY?  Not adopted.

4.5.  Eliminate =>.  Not adopted.

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU  4 Oct 88 18:22:58 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Tue, 4 Oct 88 17:21:02 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Subject: scheme-standard mailing list

The mailing list 

	scheme-standard@wheaties.ai.mit.edu

has been created for technical and administrative communication
within the IEEE Scheme standardization Working Group, which is 
open to all interested parties.  Administrative communication related
to this list, including requests for membership, should be addressed to

	scheme-standard-request@wheaties.ai.mit.edu

-- Chris Haynes (chaynes@iuvax.cs.indiana.edu)

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 19 Sep 88 16:23:00 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Mon, 19 Sep 88 15:19:51 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: IEEE Scheme Standardization Meeting

 	      IEEE Scheme Standardization Working Group

		       SUMMARY OF FIRST MEETING


The Working Group on Scheme (IEEE/MSC/P1178) met on July 27, 1988,
following the Lisp conference at Snowbird, Utah. There were 30
attendees, including several who are also members of X3J13 and
ISO/SC22/WG16.

The chair's introductory remarks included the main entries in the PAR
and the main features of the IEEE standardization process.  Will
Clinger reported on the Scheme Report Workshop of July 24th, including
proposed differences between the the ``Revised^3 Report on the
Algorithmic Language Scheme'', or R3RS for short, and the forthcoming
R4RS.

There was concern that a Scheme standard not disrupt ongoing research
on Scheme, with general agreement on the following points: (1) The
Scheme standard should encourage evolution of the language, including
alternate programming styles.  (2) The standard is incomplete, so
implementations are expected to extended the standard.  (3) Early
standardization of features should be avoided, so that research on
improved features is not curtailed.

David Bartley, Chris Hanson, and Jim Miller were elected to edit
the standard.

The main part of the meeting was general discussion, for the benefit
of the editors, of anticipated differences between the Scheme standard
and the R4RS.

An electronic newsgroup, based at MIT, will be established for
technical and administrative communication of the working group.
When it is established, its presence will be advertised on the 
scheme newsgroup with information on how to join the new newsgroup.
Transcripts of activity in this group will be periodically mailed to
interested parties, upon request to the chair, for the benefit of
those without network connections.  Full minutes of the meeting
will be posted to this newsgroup when it is created.

It was concluded that the next meeting should be in January or
February at a location and time to be determined by the chair, most
likely in Cambridge.

The working group anticipates the following time schedule: 6 months --
review of first draft of standard, 12 months -- send approved draft of
standard to MSC.

-- Chris Haynes (chaynes@iuvax.cs.indiana.edu)


Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 16 Sep 88 11:23:20 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Fri, 16 Sep 88 10:21:27 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: cph@kleph.ai.mit.edu
Subject: Re:  "DEFLET"?
Cc: rrrs-authors@mc.lcs.mit.edu

	Just a short hysterical note: it arose because of the similarities of
	
	   ((NAMED-LAMBDA (<let-tag> id1 ...) body) val1 ...)
	   and
	   ((NAMED-LAMBDA (name id1 ...) body) val1 ...)

        ...

The named form of "let" was also in Chez Scheme for a while, and in a
version of Scheme I wrote before Chez Scheme, called C-Scheme (the C was
for "curry", though C-Scheme was written partly in C.)  It made sense
there because
    (lambda <name> (id ...) exp ...)
was an abbreviation for
    (rec <name> (lambda (id ...) exp ...))
and yes, I called the former the "named form of 'lambda'", and the named
form of "let" was a natural extension.

The named form of "lambda" was shot down by the dot interface, which is
one reason why I moaned and groaned about the dot interface.

Kent

Received: from kleph (TCP 2212600254) by MC.LCS.MIT.EDU 14 Sep 88 21:11:45 EDT
Received: by kleph.AI.MIT.EDU; Wed, 14 Sep 88 21:13:20 edt
Date: Wed, 14 Sep 88 21:13:20 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8809150113.AA07343@kleph>
To: wand@corwin.ccs.northeastern.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Wed, 14 Sep 88 16:27:37 EDT <8809142027.AA28938@corwin.CCS.Northeastern.EDU>
Subject: "DEFLET"?
Reply-To: cph@zurich.ai.mit.edu

   Date: Wed, 14 Sep 88 16:27:37 EDT
   From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>

   Maybe the reason we're having such problems picking a name for this thing is
   that it was a bad abstraction in the first place.  While it is syntactically
   like LET, the binding it does is very different.

   The name seems to have arisen purely from the syntactic similarities of

   ((LAMBDA (id1 ...) body) val1 ...)
   and
   ((REC name (LAMBDA (id1 ...) body)) val1 ...)

Just a short hysterical note: it arose because of the similarities of

   ((NAMED-LAMBDA (<let-tag> id1 ...) body) val1 ...)
   and
   ((NAMED-LAMBDA (name id1 ...) body) val1 ...)

where NAMED-LAMBDA had (at that time) the REC semantics, and <let-tag>
was a special name which could not be produced by the MIT Scheme
reader.  As you can see, these two differed only in their name, thus
it seemed like a natural extension to LET.

While I won't argue for this syntax based on semantic similarities to
anonymous LET, I will argue that for terseness and readability it is
very good.  The initialization forms appear right up front, followed
by the body, and there are no extraneous keywords.

Received: from helios.northeastern.edu (TCP 20102400402) by MC.LCS.MIT.EDU 14 Sep 88 16:32:09 EDT
Received: by helios.northeastern.edu id aa06569; 14 Sep 88 16:31 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
          id aa06552; 14 Sep 88 16:27 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.5)
	id AA28938; Wed, 14 Sep 88 16:27:37 EDT
Date: Wed, 14 Sep 88 16:27:37 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8809142027.AA28938@corwin.CCS.Northeastern.EDU>
To: Alan@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Fri, 9 Sep 88 17:09 EDT <19880909210910.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: "DEFLET"?

Maybe the reason we're having such problems picking a name for this thing is
that it was a bad abstraction in the first place.  While it is syntactically
like LET, the binding it does is very different.  In 

(LET ((id1 val1) (id2 val2) ...) body)

the id's are bound, whereas in

(LET name  ((id1 val1) (id2 val2) ...) body)

name is the variable which is bound.  The id's are bound momentarily to the
val's when name is invoked, but that is temporary.

In anonymous LET, the binding is an efficiency hack which implements the
textual substitution

body[vals/ids]  

[mod side-effects, etc, which are surely irrelevant.  Another irrelevant aside
is that the typing rules in ML treat LET as if it did the substitution.]

In named LET, no such textual interpretation seems possible.  The name seems
to have arisen purely from the syntactic similarities of

((LAMBDA (id1 ...) body) val1 ...)
and
((REC name (LAMBDA (id1 ...) body)) val1 ...)

The abstraction seems to be: create a local procedure (recursion, iteration,
recurrence, whatever), and invoke it on some values.

Maybe we should redesign the syntax to more properly represent what's going
on:

(INVOKE-LOCAL (name ((id1 &INITIALLY val1) (id2 &INITIALLY val2) ...))
	body)

:-)  --Mitch

Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 SEP 88  16:49:32 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA00716@VX.LCS.MIT.EDU>; Sun, 11 Sep 88 16:52:58 edt
Date: Sun, 11 Sep 88 16:52:58 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: Alan@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re:  "DEFLET"?

I like something like CALLED-LET, as Alan suggested. This has the distinct
advantage of having a double meaning: it means both that the LETed construct
is named (CALLED something) and that it is invoked (CALLED, as APPLIED).

A more concise naming cannot be imagined. <<Vive le double entendre!>>

								~Ziggy

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Sep 88 05:28:26 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04362; 10 Sep 88 5:19 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa06499; 10 Sep 88 4:59 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA09737; Sat, 10 Sep 88 01:17:12 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
	id AA21652; Sat, 10 Sep 88 01:18:41 PDT
Date: Sat, 10 Sep 88 01:18:41 PDT
From: Norman Adams <adams@tekchips.crl>
Message-Id: <8809100818.AA21652@tekchips.CRL.TEK.COM>
Subject: re- named-let
To: rrrs-authors@mc.lcs.mit.edu

Maybe the important thing about NAMED-LET is self-application.  
And in light of all the recent thrashing on this topic,
I like the sound of "WHY-LET", or just "WHY".  

If you consider NAMED-LET as a pretty face for the simplest uses of the Y
operator, then you might like the name "Y0". (That is why-zero, but 
if you mistake the zero for an oh, and you think your reading Spanish,
it still makes sense.)  Squint your eyes, and you've got "WHYNOT".

-Norman
-------

Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU  9 Sep 88 17:09:35 EDT
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 133680; Fri 9-Sep-88 17:09:23 EDT
Date: Fri, 9 Sep 88 17:09 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: "DEFLET"?
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8809071414.AA17305@murren>
Message-ID: <19880909210910.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>

I would also like to object to the name "RECUR", and for the same reasons
given by Hal.

The "REC" in the name "LETREC" bothers me somewhat too, but in that case
the name at least suggests that it is the LETing that is recursive, rather
than any control structure.

I would prefer a name that emphasizes the naming aspect.  My personal
choice would be "LABEL", since that name was onced used in Lisp for a
similar construct, but I understand the objections.  Here are some naming
related word that I just pulled out of my thesaurus:
    
	ALIAS		APPELATION	CALLED
	DUB		ENTITLE		IDENTIFY
	MONIKER		TAG		TITLE

Anybody feel inspired?  You can try constructing names with these as roots.
How about "DUBBED-LET"? "LET-CALLED"?  (I kind of like just "MONIKER"...)

Taking another direction, how about a name that emphasizes that the thing
is a combination of LET and DEFINE?  Like "DEFLET"?

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU  8 Sep 88 03:06:21 EDT
Received: from RELAY.CS.NET by XX.LCS.MIT.EDU with TCP/SMTP; Thu 8 Sep 88 03:05:07-EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab16872; 7 Sep 88 20:15 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id aa17053;
          7 Sep 88 19:33 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
	id AA25421; Wed, 7 Sep 88 08:51:27 edt
Date: Wed, 7 Sep 88 08:51:27 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Wed, 7 Sep 88 08:51:27 edt
To: springer.2@cs.brandeis.edu
Cc: rrrs-authors.2@cs.brandeis.edu
In-Reply-To: George Springer's message of Tue, 6 Sep 88 21:03:25 EST <8809070236.AA17037@zurich>
Subject: Compromise

PLEASE, NO!!!  My understanding of the evolving discussion was that
named let was perceived by most participants as a binding construct,
and the proposed name does not reflect that.  I point out that the
Scheme community did NOT pick the name letrec (used in an argument
favoring "recur"); it was chosen by the mathematical logic/computer
theory community long before its introduction into Scheme and has a
very specific technical meaning of which the Scheme version is a
modified instance.  I, at least, agreed to that name because of its
accord with established mathematical convention.  I believe that
"recur" does NOT have such a justification and leads to the
misunderstanding that the form has something to do with recursion --
in the sense of process rather than procedure -- a perception that we
should NOT reinforce.

Sorry.

--Jim



Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU  7 Sep 88 10:18:04 EDT
Received: by MURREN.AI.MIT.EDU; Wed, 7 Sep 88 10:14:09 edt
Date: Wed, 7 Sep 88 10:14:09 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809071414.AA17305@murren>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Tue, 6 Sep 88 21:03:25 EST
Subject: demur on recur
Reply-To: hal@zurich.ai.mit.edu


I'm sorry to be cantankerous	, but I really do not like the name RECUR.
I think it is setting up a pedgogical trap.

In my experience teaching programming, one of the things I find that I
need to overcome is students' tendency to confuse control structures
with particular syntactic keywords.  For example, many of then think
(possibly to due to Pascal-itis) that "iteration" means DO or WHILE.
This is a natural mistake for people to make, because general shapes
of process evolution (such as iteration or recursion) are much more
abstract than visible keywords, so it becomes easy to latch onto the
keywords and forget about the processes.

This is part of the reason why Gerry and I, in writing SICP, did not
use DO or any other iteration construct.  Where Kent says that he
wants students to realize that "iteration is a special case of
recursion" I am more concerned that they realize that "both iteration
and recursion are special cases of ordinary procedure invocation",
that is, that there is no magic going on in these constructs and that
once the interpreter can handle procedure invocation, all the rest is
syntactic sugar.

My objection to RECUR is that it is setting up a trap for students to
think that recursion is something that is done with RECUR.  I can
easily imagine some of them getting into a state where they believe
that there are two kinds of recursion: a "simple" one that is done
with RECUR, and a "general" one that is done with ordinary function
calling; and will somehow think that the interpreter handles these in
different ways.

So I am all in favor of getting rid of overloading the LET keyword --
as George said, puns cause confusion.  But let's not replace this with
a worse confusion.  Let's pick a name that does not imply any
particular control structure.


Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU  6 Sep 88 22:05:59 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Tue, 6 Sep 88 21:03:25 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Compromise

On Aug. 26, Gerry sent the following:

     Perhaps the correct stance is that the existing named let syntax
     continue to be supported for those who like it and a new special form
     be allocated for those who would like an alternative that they find
     more appropriate for their teaching style.

     I generally don't like allocating reserved words, but sometimes I
     think it is necessary to compromise on such an issue.  Why not have
     Kent and George choose their favorite, and we can all agree not to
     argue too strongly about it.

     Please pick a pretty name that is not likely to conflict with anyone's
     current usage.  Thank you.

After looking at all of the names suggested, I think recur is the one
that I choose.  Kent strongly agrees with this proposal.  Kent gave a
persuasive rationale for selecting recur and I concur with him.  Can
we now go along with Gerry's suggestion for compromise?

Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU  5 Sep 88 20:07:09 EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Mon, 5 Sep 88 17:05:34 PDT
Received: by fog.cs.uoregon.edu; Mon, 5 Sep 88 17:05:27 PDT
Date: Mon, 5 Sep 88 17:05:27 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8809060005.AA04174@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: minutes from Utah

I'm sorry I haven't yet typed up my minutes for posting to this group.
Excuses:  I've moved from Hillsboro to Eugene, sold a house, taken a
vacation, and so forth.  I'm getting settled now and should be able to
post the minutes within a few days, by which time I should have learned
how to use this mail system and editor.

Speaking of mail, complaints and other communications should be sent to
my new electronic mail address:

    will@cs.uoregon.edu

Electronic mail sent to my old address at Tektronix will probably get to
me eventually, but everyone will be happier if you use the new address.

Peace, William Clinger

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU  5 Sep 88 18:29:00 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
To: rrrs-authors@mc.lcs.mit.edu
Path: iuvax!chaynes
From: chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Sender: chaynes@iuvax.cs.indiana.edu
Newsgroups: cs.scheme.rrrs
Subject: Re: problems with named-let
Message-Id: <12416@iuvax.cs.indiana.edu>
Date: 5 Sep 88 20:54:29 GMT
References: <33000313@iuvax> <33000314@iuvax>
Reply-To: iuvax!chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Organization: Indiana University CSCI, Bloomington

I agree with Kent that we should view iteration as a special case of
recursion, and there is a precedent for this: the REC in LETREC.  This
makes RECUR especially appropriate, since it is just a sugared LETREC.
Though RECUR is my choice of all the names for named let I've heard so
far, I'm not as opposed to NAMED-LET as Kent is.

Personally, I've always found named LET natural and use it a lot in
"private" code, though I never like the syntax overloading it
involves.  However, I too have had difficulty explaining it to others,
so I avoid it in code students may see.  I also respect the opinions
of others who have had much more experience trying to teach it than I,
and most of them have had substantial difficulty teaching it.

I'm willing to keep the named let behavior of LET if it is a necessary
compromise to add a new name for it, but I find having both in the
language distastful.  It inevitably resuls in confusion, and makes our
problems a part of our legacy.  In a number of other cases where we've
allowed two names for the same thing as a compromise we've eventually
ended up flushing one of them.



Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  5 Sep 88 16:43:32 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa09493; 5 Sep 88 16:40 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id ac00385;
          5 Sep 88 16:23 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
	id AA13838; Mon, 5 Sep 88 12:00:04 edt
Date: Mon, 5 Sep 88 12:00:04 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Mon, 5 Sep 88 12:00:04 edt
To: hal.2@cs.brandeis.edu
Cc: dyb.2@cs.brandeis.edu, rrrs-authors.2@cs.brandeis.edu
In-Reply-To: Hal Abelson's message of Sun, 4 Sep 88 14:16:36 edt <8809041816.AA11136@murren>
Subject: problems with named-let

Two other naming suggestions: NAMED

or (gasp)

(NAMED <symbol> LET <bindings> . <body>)

--Jim

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU  5 Sep 88 00:58:15 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Sun, 4 Sep 88 23:55:40 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: hal@ZURICH.AI.MIT.EDU
Subject: Re:  problems with named-let
Cc: rrrs-authors@mc.lcs.mit.edu

> From: Hal Abelson <hal@murren.ai.mit.edu>
> Subject: problems with named-let

> Your mail mentioned "other problems with named let" besides the
> overloading of LET.  I thought that this was the major objection.  What
> are some others? I'm curious about this, since I'm guessing that it
> has to do with how you introduce it to students and I'd like to know.

It has to do with the more serious issue of abstraction that I talked
about in an earlier note, all or most of which applies equally well to
"named-let" as to "let" because "named-let" is called "named let".

> How do you feel about calling this TAG or LABEL?  I don't like RECUR
> since it sounds too much like "recursion".  Pedagogically, I feel
> nervous about naming this construct something that implies that it is
> evolves a particular "shape" of process, such as recursion or
> iteration.  I do like LABEL or TAG or NAMED-LET because it draws
> attention the fact that something is being named, which for students
> is a nice point.

I believe that anything we can do to emphasize that iteration is a
special case of recursion is ultimately to the benefit of the student.
This is one of the main reasons I like "recur".  I can see why you
think it is beneficial to draw attention to the fact that something is
being named, but I think it is far more important that the name
describe what the entire form (usually) does.  It is clear that the
entire form usually performs some sort of recursion, so "label", "tag",
and "named-let" are all inappropriate.

Kent

Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU  4 Sep 88 14:20:11 EDT
Received: by MURREN.AI.MIT.EDU; Sun, 4 Sep 88 14:16:36 edt
Date: Sun, 4 Sep 88 14:16:36 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809041816.AA11136@murren>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: problems with named-let
Reply-To: hal@zurich.ai.mit.edu


Your mail mentioned "other problems with named let" besides the
overloading of LET.  I thought that this was the major objection.  What
are some others? I'm curious about this, since I'm guessing that it
has to do with how you introduce it to students and I'd like to know.

How do you feel about calling this TAG or LABEL?  I don't like RECUR
since it sounds too much like "recursion".  Pedagogically, I feel
nervous about naming this construct something that implies that it is
evolves a particular "shape" of process, such as recursion or
iteration.  I do like LABEL or TAG or NAMED-LET because it draws
attention the fact that something is being named, which for students
is a nice point.


-- Hal



Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU  4 Sep 88 14:11:17 EDT
Received: by MURREN.AI.MIT.EDU; Sun, 4 Sep 88 14:08:05 edt
Date: Sun, 4 Sep 88 14:08:05 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809041808.AA11117@murren>
To: gls@Think.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 2 Sep 88 13:34:53 EDT <8809021734.AA08862@joplin.think.com>
Subject: named let -> ???
Reply-To: hal@zurich.ai.mit.edu

   Let's get this straight:

   The name of it is called "`named let'".

   The name of it actually is "named-let".

   But it is called "named let".

   And it actually *is* "(defmacro named-let (name bindings . body) ...)"?

   --Guy

Yes, that's right.  Also, if if we optionally allow the current syntax

     (let <name> <bindings> . <body>)

then the name of it could also be called "a named form of let".


Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  2 Sep 88 14:43:41 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA13650; Fri, 2 Sep 88 14:42:12 EDT
Posted-Date: Fri, 2 Sep 88 14:43:26 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA07265; Fri, 2 Sep 88 14:43:26 EDT
Date: Fri, 2 Sep 88 14:43:26 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809021843.AA07265@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let ::: call it A-LET-NAMED


If we call it A-LET-NAMED,  you can have code that looks like:

(a-let-named loop ((a 0))
  ....
  )

Makes it sound epic.  (Just kidding.)
John

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU  2 Sep 88 13:37:06 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 2 Sep 88 13:21:38 EDT
Received: by joplin.think.com; Fri, 2 Sep 88 13:34:53 EDT
Date: Fri, 2 Sep 88 13:34:53 EDT
From: gls@Think.COM
Message-Id: <8809021734.AA08862@joplin.think.com>
To: hal@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Thu, 1 Sep 88 14:38:14 edt <8809011838.AA04335@murren>
Subject: named let -> ???

   Date: Thu, 1 Sep 88 14:38:14 edt
   From: hal@murren.ai.mit.edu (Hal Abelson)
   Reply-To: hal@zurich.ai.mit.edu


   With acknowledgement to Lewis Carroll's well-known distinctions--

   Since named let is already called named let, and we have already
   agreed to optionally keep the current syntax, which calls the name of
   named let a named form of let, why don't we just name it named-let, to
   minimize the confusion?

   -- Hal

Let's get this straight:

The name of it is called "`named let'".

The name of it actually is "named-let".

But it is called "named let".

And it actually *is* "(defmacro named-let (name bindings . body) ...)"?

--Guy

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU  1 Sep 88 21:36:56 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Thu, 1 Sep 88 20:31:41 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: hal@ZURICH.AI.MIT.EDU
Subject: Re:  named let -> ???
Cc: rrrs-authors@mc.lcs.mit.edu

	Date: Thu, 1 Sep 88 14:38:14 edt
	From: Hal Abelson <hal@murren.ai.mit.edu>
	Subject: named let -> ???
	
	With acknowledgement to Lewis Carroll's well-known distinctions--
	
	Since named let is already called named let, and we have already
	agreed to optionally keep the current syntax, which calls the name of
	named let a named form of let, why don't we just name it named-let, to
	minimize the confusion?
	
	-- Hal

The name "named-let" has many of the same problems as the named form of
"let", so it would be senseless to make this change.  Gerry proposed that
George and I pick a name.  I suggested "recur" as the name, and George
tells me that "recur" is his choice as well.  So please, let's just plan
to add "recur", leave the named form of "let", and then let's get on to
other problems.

Kent

Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU  1 Sep 88 15:44:22 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 1 Sep 88 15:41:33 edt
Date: Thu, 1 Sep 88 15:41:33 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8809011941.AA21774@dumbo>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 1 Sep 88 15:02:02 EDT <8809011902.AA06429@huxley.sun.uucp>
Subject: NAMED-LET sounds good to me, too.
Reply-To: arthur%zurich@mc.lcs.mit.edu


NAMED-LET is fine by me, too, as long as we don't remove the existing syntax.

Arthur

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  1 Sep 88 15:02:39 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA23322; Thu, 1 Sep 88 15:00:49 EDT
Posted-Date: Thu, 1 Sep 88 15:02:02 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA06429; Thu, 1 Sep 88 15:02:02 EDT
Date: Thu, 1 Sep 88 15:02:02 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809011902.AA06429@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Thu, 1 Sep 88 14:38:14 edt <8809011838.AA04335@murren>
Subject: NAMED-LET sounds good to me.

   Posted-Date: Thu, 1 Sep 88 14:38:14 edt
   Date: Thu, 1 Sep 88 14:38:14 edt
   From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
   Reply-To: hal@zurich.ai.mit.edu


   With acknowledgement to Lewis Carroll's well-known distinctions--

   Since named let is already called named let, and we have already
   agreed to optionally keep the current syntax, which calls the name of
   named let a named form of let, why don't we just name it named-let, to
   minimize the confusion?

   -- Hal

This sounds quite sensible to me.  I am sold!  I vote for NAMED-LET.
John





Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU  1 Sep 88 14:40:52 EDT
Received: by MURREN.AI.MIT.EDU; Thu, 1 Sep 88 14:38:14 edt
Date: Thu, 1 Sep 88 14:38:14 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809011838.AA04335@murren>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 1 Sep 88 11:49:55 EDT <8809011549.AA06194@huxley.sun.uucp>
Subject: named let -> ???
Reply-To: hal@zurich.ai.mit.edu


With acknowledgement to Lewis Carroll's well-known distinctions--

Since named let is already called named let, and we have already
agreed to optionally keep the current syntax, which calls the name of
named let a named form of let, why don't we just name it named-let, to
minimize the confusion?

-- Hal


Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  1 Sep 88 11:50:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA17410; Thu, 1 Sep 88 11:48:41 EDT
Posted-Date: Thu, 1 Sep 88 11:49:55 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA06194; Thu, 1 Sep 88 11:49:55 EDT
Date: Thu, 1 Sep 88 11:49:55 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809011549.AA06194@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Wed, 24 Aug 88 12:47:18 EDT <8808241647.AA04415@joplin.think.com>
Subject: named let -> ???

   Posted-From: The MITRE Corp., Bedford, MA
   Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
   Date: Wed, 24 Aug 88 09:02:34 EDT
   From: ramsdell%linus@mitre-bedford.arpa

   Was there any agreement reached on the new name for named let?
   John

I guess the answer is no.


Here are some more names to ponder:  LET-TAG, LET-MARK, LABEL,
LET-LABEL, LET-REF, LET-NOTE, and LET-NAMED.  There were many other
proposals generated quite awhile ago when this subject was last
discussed.  Would someone retrieve those suggestions?  Search for
LABEL, as I remember I once suggested it near the time the subject was
discussed. 

John

PS. I hope we do not decide this issue based on what can be taught to
first year students.  After all, they can do quite well using just
ordinary LET and local DEFINE's.

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 30 Aug 88 00:52:55 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Mon, 29 Aug 88 23:51:02 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jmiller%cs.brandeis.edu@RELAY.CS.NET
Subject: Re:  named-let proposal
Cc: rrrs-authors@mc.lcs.mit.edu

> I understand that this ordering is repugnant to the folks at Indiana,

I do not find your method of introducing students to internal "define"s
first, "let" second, and named "let" third "repugnant".  However, I do
have problems with it.  We use "letrec" for two reasons other than the
obvious historical reason.  The first is that internal "define"s look
like imperative operations, whereas "letrec" bindings do not.  The
second is that "letrec" emphasizes the relationship between names and
values, as does "let"; with "letrec" this relationship is a circular
one.  In my opinion, this relationship is not as easy to see with
internal "define"s.  We spend a lot of time trying to be sure that
students learn that names and procedures are separable, i.e., that the
relationships between names and procedures are external in that they
depend on the binding construct.  This is why we use "lambda" every
time we define a procedure at top level, e.g.:

   (define id (lambda (x) x))

instead of using the shorter "defun"-style syntax:

   (define (id x) x)

This also explains why we prefer "rec" to "named-lambda".  These may
seem like picky points to many (most?), but we want to be sure that the
syntax we use does not give false impressions.

Kent

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 30 Aug 88 00:39:56 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Mon, 29 Aug 88 23:35:59 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let again

I think I have figured out just why I do not like named "let", though I
am sure others are bound to disagree with my reasoning.  It has to do
with abstraction.  To wit, the "just giving a name to one more piece of
the transformation" argument does not work if you are trying to look at
things abstractly.  Once we understand that "let" is shorthand for
direct application of "lambda", we forget it, and rightly so.  "let"
expresses the local binding of variables to values, and the fact that
the local binding is accomplished by direct application of a "lambda"
expression is irrelevant.  For the same reason, David Bartley's
argument in favor of named "let" is not persuasive, since local binding
is not the same thing as looping or recurring.  In naming something, we
should consider what it expresses rather than how it works.  That is
why I like the name "recur", and I think David's argument against it is
weak.  If you look at how the construct works, i.e., by creating a
procedure and invoking it, then "recur" does not make sense.  But if
you look at what it expresses, i.e., a loop or recurrence, then "recur"
does make sense.  Perhaps the name "recurrence" would make slightly
more sense than "recur" if it were not twice as long as "recur".

I am willing to go along with Gerry's suggestion and add "recur" to the
report as optional syntax.  We can put both forms of "let" together
where the unnamed form is now and say that the named form of "let" is
the same as "recur".  "recur" would be described where the named form
of "let" is currently.

Kent

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Aug 88 11:37:07 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa14359; 28 Aug 88 11:36 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id ac27495;
          28 Aug 88 11:21 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
	id AA10037; Sat, 27 Aug 88 19:04:42 edt
Date: Sat, 27 Aug 88 19:04:42 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Sat, 27 Aug 88 19:04:42 edt
To: rrrs-authors.2@cs.brandeis.edu
In-Reply-To: George Springer's message of Thu, 25 Aug 88 10:57:09 EST <8808251632.AA16299@zurich>
Subject: named-let proposal

*Sigh* I've said this privately to several people, but it seems time
to state it publically: I have taught a number of freshman (admittedly
at MIT, but I will repeat the experiment this semester at Brandeis)
and have encountered no trouble in teaching named let.  The trick
appears to be in introducing things in the following order:

(a) Internal (not incremental) define for making internal loops; a la
Abelson and Sussman book.

(b) Introducing let with many examples as a binding form.

(c) Finally, after the frustration of two weeks of writing loops that
are hard to read because the initial conditions appear at the END of
the program, introducing the name in a let to make the "loop" easier
to read.

I understand that this ordering is repugnant to the folks at Indiana,
but I submit that this form of repugnance doesn't really justify a
language change, and it appears to be the ONLY issue.

One final note: I find it virtually impossible to believe that
students at Indiana can easily and comfortably navigate their way
through the early introduction of lambda and letrec, and then stumble
on named let.  Even some of our seniors have trouble reading programs
that use letrec to completely replace internal define!

--Jim Miller

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 26 Aug 88 15:29:55 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 AUG 88 12:22:25 PDT
Date: Fri, 26 Aug 88 12:22:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Why named LET anyway?
In-reply-to: "ziggy@VX.LCS.MIT.EDU's message of Wed, 9 Mar 88 06:32:21 est"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880826-122225-6327@Xerox>

Personally, I see named let, letrec, and let* as having three very different
uses.  Named let is for loops and other single-function recursions in which I
wish immediately to call the function after its binding.  Letrec is for
multiple-function recursions and those single-function ones in which there is
other work to be done before calling the function.  Let* is completely unrelated
to recursion and is simply to avoid the indenting complexity of
immediately-nested (unnamed) lets.

Both named let and letrec can be simulated reasonably well with internal
defines, but for named let cases, I find the extra overhead of breaking out the
function definition explicitly in a define a bit distasteful and a bit harder to
read.  Really, it is a matter of taste.  I do use internal defines quite
extensively for the definition of locally-required auxillary functions,
recursive or otherwise.  I think, though I 'm not really aware of it at the
time, that I usually avoid letrec in favor of internal defines, simply for
indenting reasons.

I hope that I've made one programmer's reasoning clear.

As for SI&CP being considered a good book in spite of its silence on let*,
letrec*, and named let, it is worth remembering that the book does not have as
its major purpose the teaching of the Scheme programming language, but rather
some concepts much more general than that.  For its particular pedagogical
purposes, internal defines are entirely sufficient.

	Pavel

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 26 Aug 88 15:11:23 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 AUG 88 12:10:13 PDT
Date: Fri, 26 Aug 88 12:10:08 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Clarification on named let
In-reply-to: "springer@iuvax.cs.indiana.edu's message of Fri, 26 Aug 88 00:09:37
 EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880826-121013-6303@Xerox>

Re: ``bindlet'':  Oops.  Ahem.

Re: ``bindrec'': How will a naive user keep it separate in their mind from
``letrec''?

Re: a picky point concerning the expansion of named ``let'':  Actually, the R3RS
expansion is a bit more complex than you said, since the evaluation of the
bound-variable expressions is not in the scope of the name of the ``let'':
	(let name ((i e) ...) b ...)
	((letrec ((name (lambda (i ...) b ...)))
	    name)
	 e ...)

Changing the reserved word that goes at the front of the named-let form will not
in any way simplify the expansion, so I don't much care how complex the
expansion is (at least if we all agree that it's a useful idiom at all).  In
what way will changing the reserved word make teaching this form any easier?

I don't understand Daniel Weise's (rhetorical) question, ``why should such a
simple syntactic modification change the meaning so much?''  As far as I can
tell, the only change to the meaning is that one more name is bound over the
scope of the body.  This is no more major a change than the addition of another
variable/value pair to a normal let.  My very point about the named form of
``let'' is that it is a very minor extension of the semantics.

Please, teachers, answer this question for me:

What goes wrong when you explain named-let as being exactly like the unnamed
kind except that one more thing has been given a name?  That is, we have named
the ``lambda'' that encapsulates the body.  I assume that you do not teach
``let'' as a special form but as a useful abbreviation for an applied
``lambda''.  If this assumption is not true, then that explains much and I
change my question to ``why don't you teach it as an abbreviation?''

Again, I'm not trying to claim that the way you're teaching things is wrong, I'm
trying to understand what breaks down when you try it this way.  I am also a
teacher, but have never taught a course in Scheme, so I'm trying to use your
experience to understand what does and doesn't work in the classroom, and why.

Thank you for your time,

	Pavel


Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 AUG 88  14:39:12 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA01957@VX.LCS.MIT.EDU>; Wed, 9 Mar 88 06:32:21 est
Date: Wed, 9 Mar 88 06:32:21 est
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Why named LET anyway?


 At the risk of beating a dead horse...

As a programmer who daily hacks in Scheme, it is
indeed useful to have LETREC, LET*, named-LET ...
but as a student in the MIT Intro. Programming
course years ago (6.001) I was always contented
with mere LET and internal DEFINE. I was never
confused and, although I noticed that frobs like
named-LET save on average 15-20 keystrokes, I did
not feel an unquenchable desire for a cliche macro.

Why exactly do some of you find it necessary to
teach your students about these variant forms?
Couldn't an argument be made that it is better to
teach a minimum of mechanism to a student and save
the niceties for ``professional'' programmers?
Unless your course purports to teach ``profession''.

This is not intended as a flame... I hope to learn
something by your replies.
				~Ziggy

P.S. Note that SI&CP do not mention LET* or LETREC
     or named-LET, yet many consider it a good book.

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 26 Aug 88 14:34:43 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 26 Aug 88 14:30:11 EDT
Received: by joplin.think.com; Fri, 26 Aug 88 14:33:12 EDT
Date: Fri, 26 Aug 88 14:33:12 EDT
From: gls@Think.COM
Message-Id: <8808261833.AA05612@joplin.think.com>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Fri, 26 Aug 88 00:09:37 EST <8808260648.AA14352@Think.COM>
Subject: Clarification on named let


I was not happy with "bindrec", but I didn't put my finger on why until
I read your most recent note (which I found very clear and to the point).

I don't like "bindrec" because the suffix "rec" doesn't mean what it
does in "letrec".  Letrec differs from let in a matter of scope only,
in that the variables to be bound are made available in parts of
the program text that would otherwise be surprising, because they
are executed before the variables are really available.  Bindrec,
on the other hand, provides an ADDITIONAL name for an additional
entity, and I regard it as secondary that this name has a rec-type
binding.

I might be happier if there were a "bind" just like bindrec, which also
gives a name to the function but not a rec-bound name.  Such a form would
of course be useless, but that's the price of symmetry.  My point is that
I believe the issue has been confused up to now because there are
separarable notions here that have been conceptually mingled because the
suffix "rec" was used to mean two different things.

It may be worthwhile to ponder whether a named letrec makes sense.
I think so, and in that case we need a name for that idea too.
Then clearly named let should not be called bindrec, for then
named letrec would be bindrecrec (more yuk).

How about letfn (and letfnrec)?

--Guy


Received: from mojave.Stanford.EDU (TCP 4405400170) by MC.LCS.MIT.EDU 26 Aug 88 12:37:01 EDT
Received: by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA05645; Fri, 26 Aug 88 09:36:05 PDT
Date: Fri, 26 Aug 88 09:36:05 PDT
From: daniel@mojave.Stanford.EDU (Daniel Weise)
Message-Id: <8808261636.AA05645@mojave.Stanford.EDU>
To: Pavel.pa@Xerox.COM
Cc: RRRS-Authors@MC.LCS.MIT.Edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Thu, 25 Aug 88 17:21:10 PDT <880825-172118-5155@Xerox>
Subject: Summarizing the named-let debate

     I'm not saying that these claims of pedagogical difficulty are
     false, just that I don't yet understand the details of the
     problem.  Could one of the educators (George? Kent?) please
     explain further just what the problem is?  It just seems that
     exploiting the close correspondence above should work well to
     make the idea clear.

I teach Stanford masters and phd students and have the same problems
George and Dan do.  To the uninitiated, "named let" is a confusing and
unnatural extension of LET.  They ask, "what's that funny identifier
doing there, and why should such a simple syntactic modification change
the meaning so much?"

Overloading LET is a surprise, it makes students unsure of what they
understand.  If we are suddenly allowed to change the meaning of LET,
then we also should be able to change LAMBDA and IF as well.

I advocate (and will use in future classes) LABEL+LET because the
form both introduces a LABEL (am I being reactionary?) and does a LET.
I dislike NAMED-LET because the let expression is not being named,
some procedure is being named.

Daniel

Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 26 Aug 88 12:15:47 EDT
Received: by ZOHAR.AI.MIT.EDU; Fri, 26 Aug 88 12:21:38 edt
Date: Fri, 26 Aug 88 12:21:38 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8808261621.AA16813@zohar>
To: springer@iuvax.cs.indiana.edu, jinx@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Named-let squabble: Kiss and make up!


		I observe a bit of friction here:

A:  I find the behavior of the community incomprehensible in its
  insistence on staying with a dreadful mistake.

B:  Some people do not view it as a mistake, but rather as a natural
  extension to the LET syntax.  You are trying to portray your
  subjective arguments of elegance and taste as matters of rationality
  and clarity, and they are not, they are purely matters of taste.


    This kind of minor squabble cannot be very important.

Perhaps the correct stance is that the existing named let syntax
continue to be supported for those who like it and a new special form
be allocated for those who would like an alternative that they find
more appropriate for their teaching style.

I generally don't like allocating reserved words, but sometimes I
think it is necessary to compromise on such an issue.  Why not have
Kent and George choose their favorite, and we can all agree not to
argue too strongly about it.

Please pick a pretty name that is not likely to conflict with anyone's
current usage.  Thank you.

Received: from chamartin (TCP 2206400253) by MC.LCS.MIT.EDU 26 Aug 88 09:20:30 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Fri, 26 Aug 88 09:20:46 edt
Date: Fri, 26 Aug 88 09:20:46 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8808261320.AA07344@chamartin>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Fri, 26 Aug 88 00:09:37 EST
Subject: Clarification on named let
Reply-To: jinx@zurich.ai.mit.edu

  I find the behavior of the community incomprehensible in its
  insistence on staying with a dreadful mistake.

Some people do not view it as a mistake, but rather as a natural
extension to the LET syntax.  You are trying to portray your
subjective arguments of elegance and taste as matters of rationality
and clarity, and they are not, they are purely matters of taste.  I
have no objection with the fact that you do not like the feature, and
I'm willing to consider alternative names (although none of the ones
mentioned so far are appealing), but PLEASE let's not start accusing
each other of irrationality.

BTW, it does not seem to me that the expansion for "named" LET is
considerably more complicated than the one for "normal" LET.  It seems
to me that all the (nonexistent) hair would appear in destructuring
and associating the bindings.  Maybe your comment about the expansion
is more of a comment on the tools you are using to write your macros.

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 26 Aug 88 01:11:27 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Fri, 26 Aug 88 00:09:37 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Clarification on named let

I guess there is a general confusion about why "let" as it is currently
defined is irrational and unbecoming a language which has taken great
pains to be as clear and simple as possible.  For those who may have
forgotten, (let name ((i e) ...) b ...) cannot be rewriten with rec
because rec is not part of the rrrs language.  So, the rewriting of
named let generally takes the form of (letrec ((name (lambda (i ...) b ...)))
(name e ...)).  This is a complicated macro even with a tool like
extend-syntax.  We are talking about freshman where the requirements to
enter a state supported school are well below those of most private schools.
When you think about what simple-minded tools we've had to teach over
the last few decades, it is such a breath of fresh air to teach something
as beuatiful and elegant as Scheme.  However, the overloading of the syntax
of let is a mistake and our students, and I personally, find it abhorent.
Now what choice have you left the writers of the books who help make Scheme
a household word by encouraging the teachers throughout the world that
this stuff is indeed teachable and definitely worth knowing.  This is
our decision:  Since our sensibilites as well as our students comprehension
suffer greatly, we have opted for always using letrec.  This is painful
because that requires more than is generally necessary.  Why are we stuck
like that?  Well you see there is no macro mechanism and likely there
won't be one before our book gets out and since we wish to stay within
the bounds of the standard, we have been left with no choice.  I find the
behavior of the community incomprehensible in its insistence on staying with
a dreadful mistake.  Bright people never have difficulty with bizarre
nuances in languages.  Look at unix, for example, or worse yet, tex.
But that is not the audience we are dealing with.  We have a nice, clean
simple tool except for named let and we only need a consensus for a new
name in order to express programs in the appropriate style for freshmen.
I enjoyed reading the rationale by Pavel concerning why he did not like
my suggestion of "bindlet".  I agree with him that "bindlet" is a
bad name and that is why I did not suggest it.  I proposed bindrec, which
I still like and which I believe satisfies all of the criteria that have
been enunciated.

... George Springer

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 25 Aug 88 20:32:18 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 25 AUG 88 17:21:18 PDT
Date: Thu, 25 Aug 88 17:21:10 PDT
From: Pavel.pa@Xerox.COM
Subject: Summarizing the named-let debate
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880825-172118-5155@Xerox>

My responses to today's rash of suggestions on this debate:

I agree with Guy; his defense of the name ``reclet'' (that C programmers seems
to get along with the names ``fmod'' and ``modf'') is pretty weak stuff.  Yuk,
indeed.

I found David Bartlett's arguments, concerning ``let'' being a binding
construct, very convincing.  I think that Arthur Gleckler made the completing
point of this argument, though, when he pointed out that the named variety of
let is also purely a binding form; it simply gives a name to one more thing than
an unnamed one.

If one simply must change the name, then I also support Arthur's suggestion
there: ``named-let''.

I don't like MarkF's names, ``lambda-let'' (or ``let-lambda'') since I see no
mnemonic value in these.  ``lambda'' is not the only control construct in
Scheme, so it is not a good representative for all control notions.

George Springer's idea to use ``bindlet'' seems wrong to me as well, since
``bind'' and ``let'' feel almost like synonyms to me.

The main argument for any change at all, however, seems to come from educators,
who claim that the idea of adding recursion to a purely binding form is odd to
students.  This claim seems odd to me.  What can be so hard about ``let'' being
an abbreviation for

	((lambda bvl . body) . args)

and named ``let'' simply adding one more binding into the expansion:

	((rec name (lambda bvl . body)) . args)

I'm not saying that these claims of pedagogical difficulty are false, just that
I don't yet understand the details of the problem.  Could one of the educators
(George? Kent?) please explain further just what the problem is?  It just seems
that exploiting the close correspondence above should work well to make the idea
clear.

Until I can understand the difficulty better, I am forced to continue my support
of the current named ``let'' syntax.

	Pavel

Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Aug 88 15:38:44 EDT
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Aug 88 15:38-EDT
Message-Id: <2797529834-15567018@RTS-8>
Sender: ziggy@RTS-8
Date: Thu, 25 Aug 88  15:37:14 EDT
From: Ziggy@VX
To: rrrs-authors@mc
Subject: Re: named LET -> RECLET

 If NAMED-LET is too long, why not NLET ? LETWRETCH ?

Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 25 Aug 88 15:35:49 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 25 Aug 88 15:35:44 edt
Date: Thu, 25 Aug 88 15:35:44 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8808251935.AA15159@dumbo>
To: rrrs-authors@mc
Subject: Yet more Named Let flamage
Reply-To: arthur%zurich@mc.lcs.mit.edu


Why don't we just wait until the Macros Committee decides what the standard
Scheme macro syntax will be, and then everyone can write a macro to name named
LET whatever they like?  Point being: why waste so many computrons choosing a
name for something which already has one?

Arthur

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 25 Aug 88 13:38:18 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Thu, 25 Aug 88 12:11:28 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: KMP@SCRC-STONY-BROOK.ARPA, Pavel.PA@XEROX.COM
Subject: Re: named let -> ???
Cc: RRRS-Authors@mc.lcs.mit.edu

> I briefly worried that if you introduced a name like reclet, that someone
> would eventually come asking for recletrec, but I guess it's clear that
> such a primitive would be meaningless. Phew...
> 
> Anyway, I agree with Pavel that special syntax is better than a new name
> in this case.

This reminds me of the name I almost suggested, "let+".  (The body of
the expression is executed at least once and possibly many times.)  I
also worried about names like "letrec+", and worse, "let*+" (or was
that "let+*"?).  If we could agree to flush "let*"...

Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 25 Aug 88 12:29:02 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 25 Aug 88 12:28:50 edt
Date: Thu, 25 Aug 88 12:28:50 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8808251628.AA15067@dumbo>
To: bartley@mips.csc.ti.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: David Bartley's message of Thu, 25 Aug 88 10:07:54 CDT <8808251507.AA19443@mips>
Subject: named let -> ???
Reply-To: arthur%zurich@mc.lcs.mit.edu


LET suits me just fine, too.  Named LET is purely a binding construct; it is
only special because a name gets bound to the LAMBDA which is the LET.  Thus,
you are naming the let.  If the name does change, why not NAMED-LET ?  But I'd
rather name named LET LET.

Arthur

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 25 Aug 88 11:58:57 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Thu, 25 Aug 88 10:57:09 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named-let proposal

As the user community continues to grow at its current pace
it is emcumbent on us to recognize that many universities will
be teaching Scheme to undergraduates.  Dan Friedman and I have
been grappling with what we should do about the named let problem.
Students at Indiana University are quite confused about named
let as they are taught to understand let as a binding construct
having nothing to do with recursion.  One of the good things about
Scheme is that it is in the process of removing puns from LISP.
Now, we need to remove a pun from Scheme.  The feeling that I
got from the meeting is that we don't want to lose two aspects of
the operation.  The first is that it creates a recursive definition
and the second is that it does binding like let.  The suggestion
by Guy to introduce reclet was good because it satisfied both these
concerns, on the otherhand some were upset because it seemed to close
to letrec.  So, I will suggest bindrec.  It has both aspects and
seems easy to say.  My concern is that pedagogically, named let
in the presence of unnamed let is a disaster and since I am writing
a book for freshman and would like some way of doing named let the
time has come to resolve this issue.  

... George Springer

Received: from montreux (TCP 2212600364) by MC.LCS.MIT.EDU 25 Aug 88 11:55:19 EDT
Received: by MONTREUX.AI.MIT.EDU; Thu, 25 Aug 88 11:52:25 edt
Message-Id: <8808251552.AA21115@montreux>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let -> ???
Reply-To: markf@zurich.ai.mit.edu
Date: Thu, 25 Aug 88 11:52:18 -0400
From: markf@montreux


As David Bartley said, named let is both a binding constuct (like
let) and a control construct (like lambda), so how about lambda-let
(or let-lambda).

Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 25 Aug 88 11:45:22 EDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 450512; 25 Aug 88 11:44:13 EDT
Date: Thu, 25 Aug 88 11:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: named let -> ???
To: Pavel.PA@Xerox.COM
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: <880824-151458-2690@Xerox>
Message-ID: <880825114357.0.KMP@GRYPHON.SCRC.Symbolics.COM>

I briefly worried that if you introduced a name like reclet, that someone
would eventually come asking for recletrec, but I guess it's clear that
such a primitive would be meaningless. Phew...

Anyway, I agree with Pavel that special syntax is better than a new name
in this case.


Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 25 Aug 88 11:20:33 EDT
Received: by ti.com id AA04999; Thu, 25 Aug 88 10:19:15 CDT
Received: from mips by tilde id AA14066; Thu, 25 Aug 88 10:08:02 CDT
Received: by mips id AA19443; Thu, 25 Aug 88 10:07:54 CDT
Date: Thu, 25 Aug 88 10:07:54 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8808251507.AA19443@mips>
To: dyb@iuvax.cs.indiana.edu
Cc: Pavel.pa@XEROX.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "R. Kent Dybvig"'s message of Wed, 24 Aug 88 19:38:52 EST <8808250147.AA01590@tilde>
Subject: named let -> ???

>Date: Wed, 24 Aug 88 19:38:52 EST
>From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
> [...]
>The use of "let" with a special syntax has proven to cause problems
>for us in teaching Scheme at the introductory level, and it also makes
>it more difficult to scan a program for its control structures.  We
>have found that students have trouble understanding the similarities
>between "let" and named "let"; we had no such trouble with "recur".
>
>While I certainly prefer the name "recur" to either "reclet" or named
>"let", I understand that some people do not like the name "recur",
>because it implies that the construct is used solely for recursion
>(the fact that iteration is a special case of recursion notwithstanding).
>I suppose they will dislike "reclet" for the same reason, but if not,
>I would be happier with "reclet" than with named "let".

I hope you weren't thinking of me when you mentioned "some people,"
since I don't deny that giving the LET a name only makes sense if
recursion is going to take place.  However, I do have two objections
to the name RECUR.

(1) Named LET is both a binding construct and a control construct (and
thus is similar to LAMBDA).  As you are reading along in the program,
the first action is to bind some variables and start executing a body,
just like LET.  Thus, I see it as a binding construct primarily, and a
control construct secondarily.  (Incidentally, this is why I preferred
the keyword LABEL over REC back when that construct existed.)

(2) I associate the verb "recur" with the action of calling a
procedure recursively, not with the action of creating the procedure
to be called.  Putting the keyword RECUR in place of LET is like
putting the word GOTO in front of every labelled Fortran statement.

I'll be happy with any choice of a keyword that doesn't overly
de-emphasize the binding aspects of the construct and doesn't misplace
a perfectly good verb.  LET suits me just fine.

--db--

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 25 Aug 88 11:15:19 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Thu, 25 Aug 88 11:13:19 EDT
Received: by joplin.think.com; Thu, 25 Aug 88 11:13:49 EDT
Date: Thu, 25 Aug 88 11:13:49 EDT
From: gls@Think.COM
Message-Id: <8808251513.AA04983@joplin.think.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 24 Aug 88 14:55:42 PDT <880824-151458-2690@Xerox>
Subject: named let -> ???

   Date: Wed, 24 Aug 88 14:55:42 PDT
   From: Pavel.pa@xerox.com

   Before this looks too much like concensus, I don't like the name ``reclet'' at
   all and am perfectly happy with it being a special case of the LET syntax.
   ``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
   great difference in semantics.  I can't see how the average newcomer to the
   language is going to be able to keep them straight.

Well, I worried about this a bit before proposing it.  A (very weak)
defense is that the C folks seem to get along having two library functions
names "modf" and "fmod" that do similar but distinct things.  Yuk.

--Guy



Received: from chamartin (TCP 2206400253) by MC.LCS.MIT.EDU 24 Aug 88 22:28:48 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Wed, 24 Aug 88 22:29:18 edt
Date: Wed, 24 Aug 88 22:29:18 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8808250229.AA06590@chamartin>
To: ziggy@VX.LCS.MIT.EDU
Cc: rrrs-authors@mc
In-Reply-To: Michael R. Blair's message of Wed, 24 Aug 88 17:46:34 edt
Subject: Named LET -> RECLET

     Doesn't this generate confusion? LETREC vs RECLET?
    Why not something like ITERLET or just ILET to suggest
    that named LET is used for iteration rather than more
    general recursion (for which LETREC is used)?

I for one use it for general recursion, so any connotation of
iteration seems wrong to me.  This is the reason the original ITERATE
was renamed.

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Aug 88 20:40:45 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Wed, 24 Aug 88 19:38:52 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: Pavel.pa@XEROX.COM, rrrs-authors@mc.lcs.mit.edu
Subject: Re: named let -> ???

> Why are folks so keen on changing the name?
> 
> 	Pavel

The use of "let" with a special syntax has proven to cause problems
for us in teaching Scheme at the introductory level, and it also makes
it more difficult to scan a program for its control structures.  We
have found that students have trouble understanding the similarities
between "let" and named "let"; we had no such trouble with "recur".

While I certainly prefer the name "recur" to either "reclet" or named
"let", I understand that some people do not like the name "recur",
because it implies that the construct is used solely for recursion
(the fact that iteration is a special case of recursion notwithstanding).
I suppose they will dislike "reclet" for the same reason, but if not,
I would be happier with "reclet" than with named "let".

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Aug 88 18:39:56 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 15:14:58 PDT
Date: Wed, 24 Aug 88 14:55:42 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: named let -> ???
In-reply-to: "dyb@iuvax.cs.indiana.edu's message of Wed, 24 Aug 88 14:50:28 EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880824-151458-2690@Xerox>

Before this looks too much like concensus, I don't like the name ``reclet'' at
all and am perfectly happy with it being a special case of the LET syntax.
``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
great difference in semantics.  I can't see how the average newcomer to the
language is going to be able to keep them straight.

Why are folks so keen on changing the name?

	Pavel

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Aug 88 18:09:34 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 14:58:56 PDT
Date: Wed, 24 Aug 88 14:55:42 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: named let -> ???
In-reply-to: "dyb@iuvax.cs.indiana.edu's message of Wed, 24 Aug 88 14:50:28 EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880824-145856-2650@Xerox>

Before this looks too much like concensus, I don't like the name ``reclet'' at
all and am perfectly happy with it being a special case of the LET syntax.
``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
great difference in semantics.  I can't see how the average newcomer to the
language is going to be able to keep them straight.

Why are folks so keen on changing the name?

	Pavel

Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 AUG 88  17:38:03 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA05200@VX.LCS.MIT.EDU>; Wed, 24 Aug 88 17:46:34 edt
Date: Wed, 24 Aug 88 17:46:34 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Named LET -> RECLET


 Doesn't this generate confusion? LETREC vs RECLET?
Why not something like ITERLET or just ILET to suggest
that named LET is used for iteration rather than more
general recursion (for which LETREC is used)?

				~Ziggy

Received: from montreux (TCP 2212600364) by MC.LCS.MIT.EDU 24 Aug 88 17:36:01 EDT
Received: by MONTREUX.AI.MIT.EDU; Wed, 24 Aug 88 17:33:10 edt
Message-Id: <8808242133.AA20669@montreux>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: named let -> ??? 
Date: Wed, 24 Aug 88 17:33:07 -0400
From: markf@montreux

--------
How about letloop. Sure would minimize changes to existing
programs :-)


Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Aug 88 17:14:03 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Wed, 24 Aug 88 14:50:28 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: gls@THINK.COM
Subject: Re:  named let -> ???
Cc: rrrs-authors@mc.lcs.mit.edu

This is the first I rememeber hearing of "reclet", and I like it.

Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 24 Aug 88 12:48:32 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Wed, 24 Aug 88 12:47:10 EDT
Received: by joplin.think.com; Wed, 24 Aug 88 12:47:18 EDT
Date: Wed, 24 Aug 88 12:47:18 EDT
From: gls@Think.COM
Message-Id: <8808241647.AA04415@joplin.think.com>
To: ramsdell%linus@mitre-bedford.arpa
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.arpa's message of Wed, 24 Aug 88 09:02:34 EDT <8808241302.AA24779@huxley.sun.uucp>
Subject: named let -> ???

   Posted-From: The MITRE Corp., Bedford, MA
   Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
   Date: Wed, 24 Aug 88 09:02:34 EDT
   From: ramsdell%linus@mitre-bedford.arpa

   Was there any agreement reached on the new name for named let?
   John

The name "reclet" occurred to me at Snowbird, and Dan Friedman
informed me that I wasn't the first to think of it.
--Guy

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 24 Aug 88 10:28:45 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA05911; Wed, 24 Aug 88 09:01:52 EDT
Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA24779; Wed, 24 Aug 88 09:02:34 EDT
Date: Wed, 24 Aug 88 09:02:34 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8808241302.AA24779@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let -> ???

Was there any agreement reached on the new name for named let?
John

Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 22 Aug 88 19:10:05 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 AUG 88 15:54:05 PDT
Date: Mon, 22 Aug 88 15:54:04 PDT
From: Pavel.pa@Xerox.COM
Subject: Snowbird minutes?
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880822-155405-1202@Xerox>

Well, it's been almost a month since the meeting in Utah and I'm still in the
dark about what took place (other than a note from Guy, I think, saying
something about what was decided concerning macros).  Could someone please send
out a description of what was decided about everything else?  A lot of radical
stuff was on that agenda and I'd really like to know the directions in which my
implementation should be moving to maintain adherence to the agreed-upon
language.

Thanks,

	Pavel

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 88 12:00:34 EDT
Full-Name: 
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA00546; Fri, 22 Jul 88 11:35:26 EDT
Posted-Date: Fri, 22 Jul 88 11:35:54 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23334; Fri, 22 Jul 88 11:35:54 EDT
Date: Fri, 22 Jul 88 11:35:54 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807221535.AA23334@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel's message of Tue, 14 Jun 88 10:31:25 PDT
Subject: On Modules in Scheme: Principles and Proposals

One feature I do not like about ML's module facility of 1984 is that
mutual recursion is not allowed between objects in different modules.
Without modules, programmers can freely define mutually recursive
objects.  As a principle, it seems to me that the use of modules
should not change this capability.  Jonathan told me his proposal
could be changed to include this capability.  As a result, proposals
based on ML's modules seem to be the leading contenders for modules in
Scheme.
John

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 88 10:31:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA28458; Fri, 22 Jul 88 10:30:02 EDT
Posted-Date: Fri, 22 Jul 88 10:30:31 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA23270; Fri, 22 Jul 88 10:30:31 EDT
Date: Fri, 22 Jul 88 10:30:31 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807221430.AA23270@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 18 Jul 88 15:15:32 PDT (Mon) <8807182215.AA13178@tekchips.CRL.TEK.COM>
Subject: Making local definitions more like top-level definitions.
Old-Subject: Replace LETREC with "relaxed" internal DEFINES.


From willc:
>5.  Apparently this proposal would require readers to construct and to sort
>static dependency graphs topologically in order to understand LETREC and
>internal definitions, when the writer of the code can easily make the
>dependencies explicit by nesting the LETREC or internal definitions within
>a LET*.  If the proposal ever affects the meaning of a program, therefore,
>then either the writer of the program was deliberately being obscure or
>else the writer has made a mistake.

Two points: Eric Tiedemann talked about changing LETREC.  I don't want
to change LETREC, but once you have local definitions that act more like
top-level definitions, LETREC is redundent, and can be expunged.

The "proposal" would require readers to construct and sort graphs only
if they choose to read programs imperatively.  Hopefully, real
programmers would think of local definitions as equational assertions
with local scope.  The meaning of the equations is derived from their
interdepencies, not the order of presentation.  At top-level, there is
a curious interpretation of definitions which depends partly on the
order of presentation.  With the semantics I have provided, top-level
definitions could be surrounded by a LAMBDA-expression so as to become
local definitions, and their meaning would not surprise a user.  This
would make local definitions more like top-level definitions.

John

Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 21 Jul 88 19:37:28 EDT
Received: by iuvax.cs.indiana.edu; id AA06607; Thu, 21 Jul 88 18:02:20 EST
Received: by iuvax.cs.indiana.edu (5.54/1.16) 
Date: Thu, 21 Jul 88 18:02:20 EST
From: Perry Wagle <wagle@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: RE:  lisp conf scheme agenda

  I cannot make it to the the RRRS meeting on Sunday, 24 July.  I am
teaching this summer and cannot take the time off.

  I am a graduate student at IU, I have written my own Scheme System with
native code compiler on the VAX.

  Here are my comments on Will's proposed agenda found in RRRS-AUTHORS.
Some of my comments are somewhat mundane.  Some of them begin to be
profound.

  I do not feel that now is the time for a standardized Scheme.  There are
too many open issues: continuations, concurrency, macros, environments, etc.

  I apologize ahead of time for any typos or opaque writing.  I have made a
good deal of effort to remove all such, but I am now feeling rushed for time
to get this out before everybody starts flying to Snowbird Utah.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> RESERVED WORDS AND PORTABLE CODE.  Require that implementations
> provide some way for programmers to work in a syntactic environment
> containing no reserved words other than those found in the report,
> without requiring that this be the default syntactic environment.

  I'm not sure this leads to a desirable situation.  If the R*RS is so yucky
that other environments are needed to actually do real programming, why even
have the R*RS environment?  If nobody's using the R*RS environment for
serious work, then it's just a cute toy.

> DISJOINTNESS OF TYPES.  Require that the following sets of objects
> be disjoint:  booleans, pairs, symbols, numbers, characters, strings,
> vectors, procedures.  Issue: add the singleton set containing the
> empty list to the list.  Issue: remove characters from the list.
> Issue: add promises to the list, or flush force and delay altogether
> (see **OTHER PROPOSALS**).

  Lacking a reason to make life more verbose by removing all vestiges of
shorthand/overloading ("punning"), I support dividing ALL types/values into
two classes: the class of TRUE types/values, and the class of FALSE
types/values.  With this, there should be at least one true value,
designated #t, and one false value, designated #f.  I don't care whether
these values are disjoint from other values of the same class or not.

  I don't support a distinct boolean type.  If there IS a boolean type, then
there should be exactly two boolean values (values interpretable as
boolean), #t and #f, and those should be the ONLY values allowed from the
first sub-expression of an IF.  Having a distinct boolean type, and then not
really using it is ugly!  Enforcing it adds a run-time error condition check
to IF, which is undesirable.

> ELIMINATE NIL, T.  Remove nil and t from the report.

  Human engineering is wierd.  When I first learned LISP in 1975, NIL
offended me because it didn't look right (like a symbol, not a list).  Then
I started actually writing code, and discovered that "nil" was a LOT easier
to see than "()" or "'()".  And I've used NIL ever since.  When I learned
SCHEME, I (obviously) had to bow to its insistance on calling "nil" a
symbol, but I still use it when I can, simply because its still easier for
me to see!

  I propose (half jokingly) that the syntax "nil" denote the empty list and
not a symbol.  That is, the single special case of the #! syntax.

> EQV?.  Clean up the specification of eqv?, removing the requirement
> that it be true of two empty strings or empty vectors.

  My impression of Will's EQV? axioms when I scanned over them is that they
looked an awful lot like EQ? and I didn't see the point (of having something
just barely different than EQ?).

  I've always thought EQV? should return TRUE when EQ? "should" (due to
hashing) be TRUE, but isn't (bignums, strings, etc, but NOT lists).

  I don't think EQV? has the right to be unspecified on anything computable.
EQ? does have the right since it ONLY compares pointers (without EVER
dereferencing them!).

> DUPLICATE FORMALS ARE IN ERROR.  The list of formal variables in
> lambda, let, letrec, and do (but not let*) should not contain
> duplications.  E.g. (lambda (x y x) ...) is an error.  In the case
> of named let, the formals in the initial bindings list should be
> distinct, but it is ok (albeit useless) for the "name" to duplicate
> a formal.  E.g. (let foo ((x 1) (foo 2)) ...) is legal.

  Okay.  (Pssst!  What's the problem?)

> CHANGE WORDING OF LETREC RESTRICTION.  From "...without referring
> to the value of any <variable>" to "...without referring to the
> value or location of any variable".  Example:
>
>   (letrec ((wanna-be-a-doctor    'doctor)
>            (imagine-my-surprise! (begin
>                                   (set! wanna-be-a-doctor 'nurse)
>                                   'zowie)))
>     wanna-be-a-doctor)

  Closure creation refers to the locations of its free variables.  Therefore
this wording bugs me.  Why not just come out and say "without STORING or
FETCHING from the location of any LHS-variable".  The vague wording above
confuses me, and I know what it means!

> CLARIFY WORDING OF LETREC.  Add the word "ALL" as follows:
> "...in a letrec expression, ALL the bindings are in effect while
> their initial values are being computed..."

  I'd be happier with a wording of something more like: "All the
LHS-variables exist but are considered unbound while the RHS-values are
being computed.  Only when all the RHS-values have been computed are the
LHS-variables considered to the bound to their corresponding RHS-values.".

> CLARIFY MEANING OF QUASIQUOTE.  As in Pavel Curtis's proposal.

  I missed Pavel Curtis's proposal (sorry Pavel!).  However, my I already
feel that quasiquote should produce all fresh pairs.  That is,

	`(1 2 3)	expands to	(cons 1 (cons 2 (cons 3 '())))

And I will (and have) rewrite(n) quasiquote to have this behavior in scheme
systems that don't have this behavior.

> CLARIFY STATUS OF CI.  Though CI is described as a suffix,
> it is generally just embedded.

  No opinion.

> CLARIFY THE SPECIFICATION OF TRUNCATE.
> IMPROVE THE DISCUSSION OF EXACTNESS AND INEXACTNESS.
> CHANGE THE SYNTAX OF NUMBERS.
> CLARIFY THE STATUS OF EXPONENTS.
> EXPONENTS ILLEGAL IN FRACTIONS.
> EXACTNESS AND INEXACTNESS OF CONSTANTS.

  No opinion.  I haven't worried about numbers.  Yet.

> **PART 2: POLICY ISSUES**

> FLUSH OPTIONAL FEATURES.  Do away with the distinction between
> essential and optional features.  In effect, make everything
> essential.  Issue: some optional features should be dropped rather
> than made essential; which?

  My Scheme system only has integer fixnum's.  I feel that for my system to
be a "real-life scheme", it needs at least integer bignums.  On the other
hand, I don't feel in any hurry to add inexact real bignums.  Though if I
did, it would be nice if I had a standard to match up with.  A library of
standard algorithms would be nice too.

> MAKE PROCEDURES MORE REGULAR.  Add vector-copy, list-copy,
> list-fill!, list-set!, (make-list k); or remove procedures
> to make them more regular across the different kinds of
> sequences.  Issue:  what's the policy?  Issue:  generic
> copiers, fillers, etc.  Issue: optional or essential?

  It would would be nice to have a consistant set of fundamental operations.
However, though a few years back I was much in favor of generic copiers,
length measurers, etc, I am now strongly in favor of type-specific ones.
(LIST-LENGTH, STRING-LENGTH, etc).  COPY is a little stranger, in that you
might desire to copy heterogenous data structures, and in that case a generic
COPY would make sense.  Otherwise, a pair-specific copier still is useful.

> UNDERSPECIFICATION.  What kinds of underspecification are
> desirable?  What kinds are undesirable?

  No unspecification is desirable.  Optimizers should be completely
invisible.  Scheme programs should have the same behavior on all scheme
systems.  I should never have to consider "the optimizer" when I am
reasoning about my program (unless I EXPLICITLY set an optimizer level, and
in this way become implementation dependent).

*************************************************************************
*									*
*	Let me restate that as a general principle for emphasis		*
*	and clarity: My Scheme program should only become		*
*	implementation dependent if I explicitly say so,		*
*	otherwise the scheme program should be completely		*
*	portable across all scheme systems in syntax and behavior.	*
*									*
*************************************************************************

  The only reasons for underspecification I've heard are to allow
concurrency and to allow stupid optimizers.  Concurrency is out of the
question since then is no protection mechanism for critical sections.  The
concept of condoning stupid optimizers horrifies me since I can imagine with
horror one that started inlining code, and then interleaving the evaluation
of sub-expressions "for efficiency".  PERMUTE is completely undefined, you
know.  No axioms, nothing.

  Speaking of PERMUTE:  you do realize that the lack of a definition of
PERMUTE makes this touted denotational semantics incomplete to the point of
uselessness?  If non-determinism is so easy to reason about, how come the
denotational semantics can't?  How am I supposed to do my proofs with a
missing fundamental and much used definition?

  Query:  What does:

	(begin
	  (set! x 1)
	  (list (set! x (* x 3)) (set! x (+ x 4)))
	  x )

mean? (3, 5, 7, or 15?)  What does:

	(call/cc
	  (lambda (k)
	    (list (k 1) (k 2) (k 3)) ))

mean? (1, 2, or 3?)

> **PART 3: MAJOR PROPOSALS**

> MACROS.  No complete proposal is ready for consideration.  The
> macro and extend-syntax syntaxes have been proposed as least
> common denominator(s) to tide us over until we have a real macro
> proposal.

  I strongly oppose any system that won't allow me to write naive macros.
Renaming my symbols without my express permission and not telling me is not
human engineering (macro substitution is not necessarily beta-reduction!).
It simply does not scale to tractable proofs of large macros.  Other than
that extend-syntax suits me fine if it remains disjoint from the macro
expansion facility itself.

> MODULES.
> REPLACE LOAD WITH INCLUDE.  The load procedure is convenient for
> interactive program development, but its dependence on an object
> with state (the external file system) makes it less satisfactory
> than include would be for describing complete programs.
> Presumably implementations would retain load as part of their
> programming environment even if it were replaced by include in
> the report.  Issue:  An alternative is to change the meaning of
> load in the report.  Issue:  Include also depends on an external
> file system; the only difference is that the dependency is removed
> at compile time rather than run time.

  I oppose making *interactive* program development harder in favor of batch
processing.  Both LOAD and INCLUDE have their uses.  Both should be allowed.
Neither can provide the functionality of the other.

  The top-level expressions in a file being LOADed should have exactly the
same semantics as typing the expressions in, one at a time, from a
read-eval-print loop.  INCLUDE doesn't have to have this semantics.

  In fact, I'll claim that LOAD starts up a fresh read-eval-print loop,
reading from a file instead of a keyset, and writing to oblivion instead
of a screen.  It terminates upon EOF.

  I conceive of INCLUDE more like a macro that returns that contents of a
file (probably wrapped with a begin).

> FIRST CLASS ENVIRONMENTS.  In my opinion, no proposal for
> environments remains on the table.  A proposal could be built
> around make-environment, the-environment, build-environment,
> Guzowski's with, or Pavel's recently withdrawn proposal.

> ADD EVAL.  Add eval to section 6.10.4.  Issue: one or two arguments?
> If two, how do you get an appropriate second argument?

> ADD SECOND ARGUMENT TO LOAD.  If eval is added and takes a second
> argument, then shouldn't a second argument should be added to load
> also?

  The fundamental abstraction is a read-eval-print loop (REP loop).  A REP
loop reads from a stream of expressions (usually a keyset or a file (with
LOAD)) and writes a stream of values (usually a screen/window, or a datasink
(with LOAD)).  A REP loop reads expressions, evaluates them for value AND
effect, outputs their values, then starts over again.  This is a very
iterative, side-effecty approach, and I class it as one of the activities of
Meta-Programming, of which debugging is also a member.  EVAL means nothing
without a REP loop, or something like it.

  In particular, I view "define" as a command to a REP loop to add or modify
a symbol to its list of definitions (its extendable "base environment").

  So called "local defines" as they are presently defined are therefore a
complete misnomer.  They have a completely different meaning and use from
"top level defines".  I would much prefer to refer to local defines with the
keyword "declare" and NOT "define".  I don't care what "declare" means at
top level, I don't use "declare".  I do use "define" as described above.

> ADD LAMBDA*.  Adopt the Hieb/Dybvig proposal for procedures that
> dispatch on the number of arguments they are given, for allowing
> multiple values to be stored in variables, and for the & syntax.
> This proposal is an alternative to the next two proposals.

  I used Bruce Duba's "match-lambda" to write the variable argument
procedures in my scheme system.  I used the:

	(define! write-char
	  (match-lambda
	    [ (char) (write-char char (default-output-port)) ]
	    [ (char port)
	      (die-if-not-port port)
	      (die-if-not-char char)
	      (syscall #!writec port char) ] ))

style to not replicate code.  However, I did observe that this programming
approach uses MULAMBDA and thus eats PAIR's and causes garbage collections
(and my version 0 garbage collector is SLOW).

  APPLY forces its list argument into the form of an actuals-list (which is
isomorphic to a finite (acyclic) proper list).  MULAMBDA (lambda w/ #!rest)
converts actuals-lists to pair-lists.  So there is already an internal
actuals-list representation, which causes all this gyration with APPLY and
MULAMBDA.  Punning the actuals-list with multivalues-lists seems natural.

  HAVING to convert back and forth from pair-lists is inefficient and
unnecessary.

  I like the "&" proposal, but I haven't formally worked out the semantics
nor implemented it yet.

> MULTIPLE RETURN VALUES.  Add optional procedures values and
> with-values such that (values x1 ...) returns values x1 ... and
> (with-values thunk proc) calls proc on the values returned by
> thunk.  Issue: what do continuations that currently expect one
> return value do when given zero values or more than one value?
> The most popular answers are:
>
>   a.  It is an error.
>   b.  Ignore extra values; it is an error if there are no return
>       values.
>   c.  Ignore extra values; the continuation gets an unspecified
>       value if there are no return values.
>   d.  Ignore extra values; the continuation gets #f if there are
>       no return values.

  Unless the continuation takes variable numbers of arguments, it is an
error for the wrong number of values to be given to it.  General principle
holds that adding and ignoring values is bad.  Examples might convince me
otherwise.  Annotation to specify which of many values is desired is easy.

> OPTIONAL ARGUMENTS.  Add an optional #!optional syntax to lambda
> expressions to support optional arguments:
>
>   (lambda (x #!optional y z . w) ...)
> 
> If not supplied, y and z are bound to new locations holding a
> special default object.  Add the procedure default-object? so that
> (default-object? y) is true if y is not supplied.  It would be
> possible to pass the default object as an actual argument, thereby
> making it possible to obtain the default for y while specifying z
> explicitly.

  I tried using a default-object approach for my variable argument
procedures.  I dropped it in favor of the multiple formals list approach
described above, as it was clearer and shorter.

> RECORD OBJECTS.  Jonathan's proposal:

  No opinion.

  (Later) I lied.  I think RECORD OBJECTS should be a user-library module.
The need of RECORD OBJECTS to create objects of TYPE disjoint from all other
TYPEs is a very strong argument in favor of providing user defined types.
(Proposals anyone?)

> **PART 4: OTHER PROPOSALS**

> CHANGE WORDING OF SET! RESTRICTION.  From "<Variable> must be
> bound in some region enclosing the set! expression or at top
> level" to "<Variable> must be bound in an enclosing lexical
> environment".  Issue: need examples of code that illustrate
> the intended differences between the two wordings.

  If you distinguish between "define" and "declare"... (see my discussion
elsewhere) I want to define globals while embedded in LETRECs.
Also, this doesn't seem too friendly to the interactive user (who your
already dumping on anyway, but...).

> FORMAL SEMANTICS FOR NUMERIC CONSTANTS.  As proposed by Clinger,
> who doesn't think it is necessary.

  With fifty different types of numbers, something formal might be nice.

> ELIMINATE DO.  Remove do from the language.

  Won't bother me...

> ELIMINATE NAMED LET.  Remove named let from the language.

  I use REC and RECUR.

> ELIMINATE =>.  Remove the => notation from the language.

  Never used it.  (later:)  Eeek.  Never will either.

> ELIMINATE CASE.  Remove case from the language.

  HUH?!?

> ELIMINATE FORCE AND DELAY.  Or make promises disjoint from other
> types.

  I've decided to make suspensions (ala Friedman&Wise, 1976) disjoint from
other types in my Scheme System as I like to make streams of closures, and I
can't tell the difference between a closure and a suspension realized as a
closure.  And this is a problem.

> ELIMINATE LAST-PAIR.  Remove last-pair from the language.

  I've used it.  I can write one myself.

> ELIMINATE NUMERIC FORMATS.  Eliminate (or redesign or simplify)
> the format arguments to number->string.

  No opinion.

> ELIMINATE CALL-WITH-CURRENT-CONTINUATION.  Remove
> call-with-current-continuation because it makes programs hard to
> understand.

  I don't use CALL/CC (well I haven't for quite a while).  I DO use
Continuation Passing Style, and my programs are probably hard to read.  But
previously intractable programs are easy to write.  I DO support functional
continuations and prompts, and have already (ab)used engines a number of
times to partially achieve this functionality (when I couldn't convert to
Continuation Passing Style).

> DEFINE WITH NO EXPRESSION.  Optionally allow (define x) for top level
> definitions only.  Issue: why not for internal definitions?  Issue:
> If it becomes available for internal definitions, then it should also
> be available for letrec, let, let*, named let (?), and do (??).

  Do NOT allow "define" with no expression.  Do allow "declare" with no
expression.  See my earlier discussion.  No such thing as local defines.
Allow local "declare"s with no expression.

  Symmetry arguments indicate that LETREC et al should allow empty
expressions.  I wouldn't (and have never needed to) use them.

> ADD CALL.  Add essential syntax: (call proc arg1 ...).
> ADD STATIC.  Add essential syntax: (static id).

  My compiler converts to this form.  Almost.  It also puts all constants
inside of QUOTE expressions, I'm contemplating recognizing tail recursion at
this point in the compilation process by splitting CALL into CALL and GOTO,
and I already split lexical variables from globals with GLOBAL and LEXICAL
(instead of static).  I also make all variable locations explicit, but I am
probably going to retract that later on, unless I get a good algorithm for
detecting possibilities of stack-and-not-heap allocation.

  So I might be against it because its not the way my compiler would want it.
Supporting code traversers this explicitly might be a bad idea anyway.

> PEEK-CHAR.  Add a peek-char procedure.  Issue: essential?

  Would be cleaner and more robust than writing it yourself.  I'd rather
worry about the I/O package in it entirety, though.

> ADD EQ-HASH, EQV-HASH.

  No opinion.

> ADD DAYS-AFTER-J2000.0.

  I favor a full fledged date treatment system/library.

> VALUE RETURNED BY ONE-ARMED IF, COND.  Specify that (if E0 E1) returns
> #f if E0 is false, and that (cond ...) returns #f if no clauses apply.

  I don't like one-armed if's (I use WHEN and UNLESS).  I dislike
unspecified values.  #f is fine.  Just be sure to maintain tail-recursion
(Hi Bob!(:-)(:-)(:-)).

> VALUES RETURNED BY SIDE EFFECTS.  Change the semantics of
> (set! x e), (set-car! x e), (write e p), et cetera, so that
> they return the value of e.  Issue: why not return #!unspecified?

  My Scheme System returns "e".  #!unspecified is stupid.  If you are
"lucky" it induces a run-time error right away.  If you aren't, and didn't
throw it away, then your program is a time-bomb.  Either using the value of
a side-effecting expression causes a COMPILE-TIME error, or it returns a
legitimate value -- anything else is bogus.

  Anyone who doesn't use the value (ie throws it away) doesn't care what the
value is.  #!unspecified doesn't even help him, really, in the event that he
slips.  Anyone who wants to use a value needs something reasonable, and
#!unspecified isn't.  The situation is not symmetrical.

> LEFT TO RIGHT EVALUATION OF ARGUMENTS.  Change the semantics of
> procedure calls so that expressions are evaluated from left to
> right.

  It would make program proofs easier.  Combinatorial explosions tends to
make things intractable.  See my previous arguments.

> LEFT TO RIGHT EVALUATION OF DEFINITIONS.  Change the semantics
> of internal definitions so that they are evaluated from left to
> right.  Issue: do the same for letrec?

  Evaluation of RHS expressions should occur Left to Right.  Binding of RHS
values to LHS variables should occur in no particular order, though it would
be nice if the binding occurred after ALL of the RHS expressions were
evaluated.

> CHANGE THE SPECIFICATION OF AND.  Change and so it always returns
> #t or #f.  Issue:  the last position of an and becomes non-tail-
> recursive.  Issue:  If this proposal is not adopted, must and
> return the first false value it sees, or can it simply return #f?

  Why brain-damage AND?  Last position should be tail-recursive.  Non-#t
values are okay, as are non-#f values.  I don't believe in a distinct
boolean type anyway.

> RENAME CHARACTER COMPARISON PREDICATES.  Change char=? etc to
> char= etc.

  I use "char-eq?", "char-ne?", "char-ge?", etc.  Its easier for me to see,
but its non-standard, which causes boot-strapping problems.

  My feeling is that "=", "<>", "<=", etc don't need the "?" because they
already consist of special characters, and culturally are understood to
return true and false values.  This argument presumably extends to relations
with alphabetic prefixes.

> RENAME SET! TO SET.

  No.  Why?

  (Later:)  LET is the non-destructive version of SET!.  Seriously!
(That's the way I think about it sometimes).

  Chez Scheme's Fluid Bindings are another non-destructive version
of SET!.

  If I had first-class locations, I might have a third version.

> RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR.  Issue:
> non-destructive versions make sense even though they're not in the
> report.

  Not for destructive versions.

  Keep the bang ("!") notation for all.  Pronounce it as "bang" and not as
"destructively".  Easier pronunciation might make you feel better.

> RENAME CHAR-READY? TO READ-CHAR-READY?.  Issue: name:
> READY-TO-READ-CHAR?  Issue: replace instead
> with read-char? (TYI-NO-HANG)?

  READ-CHAR-NO-HANG.  For some reason I'm concerned about non-atomicity.

> RELAX THE LETREC RESTRICTION.  Require implementations to find
> an order that works, if any does.  Issue:  not computable?

  Topological sorts of dependency graphs is certainly computable.  I think
is even linear in time.  The problem is what to do with cycles.

  I'm happy with LETREC the way it is.  If somebody wants to topsort, and
solve cycles, let them write a library macro called something else, and make
it publicly available, I won't mind though...

> DON'T SPECIFY WHETHER THE EMPTY LIST COUNTS AS TRUE OR FALSE.

  I don't believe in booleans.  So I believe the empty list is a false value.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> LOOSE ENDS not in Will's note, but in typeset copy handed to be just now:

> ADD TYPE-OF: (from Pavel)

  In my implementation, there is an object of each type that doesn't exist.
This is an artifact of the linker, but rather than dismiss it as a hack, and
be rid of it, I kept them around in wait for a use for them.  (The singleton
objects: (), #t, #f, etc are all of different primitive types, but are
POINTER-EQ? to the ghost-object of their types).

  I was thinking that these ghost-objects would be ideal first-class types,
which implies that a first class type is of its own type:

	(pair? (type-of (cons 1 2))) ==> #t

  I even defined a predicate TYPE-EQ? that compares types of two objects,
which implies:

	(define ghost-pair (type-of (cons 1 2)))
	(define pair? (lambda (x) (type-eq? x ghost-pair)))

  This seems rather implementation specific, but thought I'd throw it out
to see if anyone could abstract it to something interesting.

> CHAR renamed to CHARACTER (pavel):

  I actually wouldn't mind INT, BOOL, and RAT.  But then thats largely
because my screen is only 80 characters wide.  I also find very long
identifiers hard to read.

  I guess it comes down to:  if you renamed CHAR to CHARACTER, I'd probably
rename them back.

  OH!  The real reason is that INTEGER, RATIONAL, and BOOLEAN are special.
That is, we don't have INTEGER+, INTEGER>=, RATIONAL*, RATIONAL<>,
BOOLEAN-AND, BOOLEAN-NOT, etc.  In this sense CHAR is not special, and hence
is worthy and needful of the shorter name.

> CHANGE EXPONENT MARKER from E to ^.

  It would be confusing with exponentiation in other languages...

  I like the thought, though.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> LOOSE ENDS not found in proposal anywhere:

> CASE STUPIDITY.  Is case-insensitivity while reading symbols sane?  Is it
> human engineering?  Does it open whole new realms of error making?  Is
> ASCII too powerful?  Wouldn't Morse Code be simpler?  Do you miss the
> grand old days of FORTRAN where even spaces weren't real?

  At the same time I was chafing against the limitations of only two cases
of letters in ASCII, case-insensitity is foisted upon me.  To me,
case-insensitivity is a hallmark of ANCIENT, not modern programming
languages.  But be that as it may, case-insensitivity CAUSES errors.

  I cannot believe that someone can think that "FOObaz", "FoObAz", "fooBAZ",
"foobaz", "FooBaz", "FOOBAZ", and "fOOBAz" are all the same identifier.
I've had to deal with programs that spelt keywords and variables a multitude
of ways, and it was just one more indication of the overall downright SHODDY
design.  It was just another way to be sloppy, and the compiler allowed it.

  I have two proposed solutions:

(1)  Case Consistancy: the identifier must be refered to with the same case
     signature across all usages.  To refer to both "FOObaz" and "fooBAZ" is
     a compile time error (NOT a read-time error!).

(2)  (EQV? 'FOObaz 'fooBAZ) ==> #t,  (EQ? 'FOObaz 'fooBAZ) ==> #f
     have the compiler use EQV?, and let the macro expander use EQ?,

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 21 Jul 88 09:11:13 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA17452; Thu, 21 Jul 88 09:10:11 EDT
Posted-Date: Thu, 21 Jul 88 09:10:37 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA20563; Thu, 21 Jul 88 09:10:37 EDT
Date: Thu, 21 Jul 88 09:10:37 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807211310.AA20563@huxley.sun.uucp>
To: willc@tekchips.crl
Cc: RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 18 Jul 88 15:15:32 PDT (Mon) <8807182215.AA13178@tekchips.CRL.TEK.COM>
Subject: Replace LETREC with "relaxed" internal definitions.

I just received a copy of the Proposals for a R4SR.  To my surprise, I
found my wish that a dependency analysis be done on local definitions
was taken as proposal to be discussed at Sunday's meeting.  I intended
the subject come up only in informal discussions.  In order to
realistically institute such a big change, I would have to show an
efficient implementation in both an interpreter and a compiler, and
convince a number of people it is a good idea, before the subject is
discussed at a meeting.  That time is curtainly not now.

I submitted the recent notes on this subject in response to Eric
Tiedemann's message on the specification of the order in which
elements of a combination are evaluated.  In his note, he talked about
finding an "applicative order fixpoint" of LETREC, to solve Robert
Hieb's complaint that internal definitions look like top-level
definitions, but do not act like them.  Someone then complained that
finding an applicative order fixpoint is uncomputable.  However, a
dependency analysis is all that is needed, and I gave an algorithm
that does the analysis.

Please withdraw the proposal to Replace LETREC with "relaxed" internal
definitions.  My proposal to eliminate NIL and T from the report is
quite serious.

John

Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 18 Jul 88 22:13:24 EDT
Received: by ATHENA.CS.YALE.EDU; Mon, 18 Jul 88 21:49:42 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8807190149.AA08696@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2) 
          via WIMP-MAIL (Version 1.3/1.5) ; Mon Jul 18 21:54:35
Date: Mon, 18 Jul 88 21:54:31 EDT
To: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl.arpa

I share Will's reservations about relaxing the restrictions on LETREC.
The only way I can see that makes the relaxation meaningful is to
change Scheme to a non-strict language, in which case, of course, ALL
restrictions can be removed.  But I doubt if people will like that
idea...

I seem to recall someone mentioning that dependency analysis and
re-ordering of equations is used in functional programming languages.
Let me clarify this: it is used primarily to improve efficiency, does
not change the dynamic semantics of the language, but DOES change the
static semantics.  In particular, type-correctness is impacted, by
allowing a broader class of well-typed programs under the
Hindley-Milner type system.  This is viewed as a feature, but is
subject to the same criticism that Will mentions -- if a program is
rejected as ill-typed the user may have trouble figuring out how to
fix it.  However this is not viewed as a serious problem because:

 1) such kinds of type errors are subtle even without the re-ordering!
 2) the re-ordering actually LESSONS the likelihood of such an error.

Neither of these arguments can be made in the case of LETREC.

	-Paul
-------


Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Jul 88 20:33:53 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa09388; 18 Jul 88 19:30 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa07670; 18 Jul 88 19:12 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA17770; Mon, 18 Jul 88 15:13:25 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
	id AA13178; Mon, 18 Jul 88 15:15:35 PDT
Message-Id: <8807182215.AA13178@tekchips.CRL.TEK.COM>
To: ramsdell%linus@MITRE-BEDFORD.ARPA
Cc: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl
Subject: Re: Replace LETREC with "relaxed" internal DEFINES.
In-Reply-To: Your message of Fri, 15 Jul 88 07:47:43 EDT.
	     <8807151147.AA15914@huxley.sun.uucp>
Date: 18 Jul 88 15:15:32 PDT (Mon)
From: willc@tekchips.crl

I have several comments on the proposal to "RELAX THE LETREC RESTRICTION".

1.  The proposal as submitted and entered into the agenda has no bearing
on LETREC versus DEFINE.  Presumably anything done to relax the LETREC
restriction would relax the DEFINE restriction in exactly the same way,
since internal DEFINE is defined in terms of LETREC.

2.  The compiler cannot simply be expected to "find an order that works,
if any does", since that is not computable.  (Definitely not computable;
in an earlier message I wasn't sure.)

3.  It is therefore not enough to say that the compiler must find the
"best" order, since the obvious meaning of "best" is not computable and
it isn't clear what might be meant by the best computable order.

4.  To judge by a computer program submitted by John Ramsdell, the "best"
computable order is to be defined as follows: if an order that works can be
found by examining the static dependency graph of the LETREC variables and
the expressions giving their initial values (and by examining nothing else),
then the best order is any such order; otherwise the best order is arbitrary.
This does indeed relax the LETREC restriction found in R3RS.

5.  Apparently this proposal would require readers to construct and to sort
static dependency graphs topologically in order to understand LETREC and
internal definitions, when the writer of the code can easily make the
dependencies explicit by nesting the LETREC or internal definitions within
a LET*.  If the proposal ever affects the meaning of a program, therefore,
then either the writer of the program was deliberately being obscure or
else the writer has made a mistake.

6.  (Reductio ad absurdum.)  If this proposal is adopted, then it seems to
me that compilers should be required to choose an order of evaluation of
arguments that makes code like the following work:

   (let ()
     (define x)
     (define y)
     (define z)
     ((begin (set! z 3) +) (begin (set! y 2) x)
                           y
                           (begin (set! x 1) z)))

The computation that must be performed by the compiler or human reader
for this sort of code to be guaranteed to work is exactly the same as
the computation required by the proposed relaxation of the LETREC
restriction.

7.  (Disclaimer.)  I think it is wonderful that compilers compute
dependency graphs and topological sorts and so forth in order to
generate better code, but I think it is terrible when humans must
do the same.

Peace, Will

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jul 88 13:23:05 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA11729; Mon, 18 Jul 88 13:21:22 EDT
Posted-Date: Mon, 18 Jul 88 13:21:48 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA18693; Mon, 18 Jul 88 13:21:48 EDT
Date: Mon, 18 Jul 88 13:21:48 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807181721.AA18693@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell@linus's message of Mon, 18 Jul 88 10:07:40 EDT <8807181407.AA18434@huxley.sun.uucp>
Subject: Extended local defines.

I sent the wrong version of eld.scm.  This patch makes a def one of
(DEFINE id exp) or (DEFINE (id+) body) as I originally intended.
John

*** eld__00.scm	Mon Jul 18 11:54:47 1988
--- eld.scm	Mon Jul 18 13:11:59 1988
***************
*** 6,12 ****
  ;;; ELD Scheme
  ;;; form ::= def | exp
  ;;; body ::= def* exp+
! ;;; def  ::= (DEFINE id body)
  ;;;       |  (DEFINE (id+) body)
  ;;; exp  ::= id
  ;;;       |  const
--- 6,12 ----
  ;;; ELD Scheme
  ;;; form ::= def | exp
  ;;; body ::= def* exp+
! ;;; def  ::= (DEFINE id exp)
  ;;;       |  (DEFINE (id+) body)
  ;;; exp  ::= id
  ;;;       |  const
***************
*** 76,86 ****
  (define (eld-def c def)
    (let* ((def (simplify-def def))
           (name (cadr def))
!          (body (cddr def)))
!     (eld-body (lambda (form-seq free)
!                 (c (list*3 define-kw name form-seq)
                     free))  ; Note: name may be in free.
!               body)))
  
  (define (eld-exp c exp)
    (cond ((pair? exp) (eld-exp-is-pair c exp))
--- 76,86 ----
  (define (eld-def c def)
    (let* ((def (simplify-def def))
           (name (cadr def))
!          (exp (caddr def)))
!     (eld-exp (lambda (form free)
! 	        (c (list define-kw name form)
                     free))  ; Note: name may be in free.
! 	     exp)))
  
  (define (eld-exp c exp)
    (cond ((pair? exp) (eld-exp-is-pair c exp))
***************
*** 198,206 ****
  
  (define (make-binder binder defs form)
    `((,binder ,(map (lambda (def)
!                     (let ((var (cadr def))
!                           (val (cddr def)))
!                       `(,var ,(seq->exp val))))
                    defs)
        ,@form)))
  
--- 198,204 ----
  
  (define (make-binder binder defs form)
    `((,binder ,(map (lambda (def)
!  		     (list (cadr def) (caddr def)))
                    defs)
        ,@form)))
  

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jul 88 10:10:45 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA04657; Mon, 18 Jul 88 10:07:14 EDT
Posted-Date: Mon, 18 Jul 88 10:07:40 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA18434; Mon, 18 Jul 88 10:07:40 EDT
Date: Mon, 18 Jul 88 10:07:40 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807181407.AA18434@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Extended local defines.

This is about the issue of relaxing the local DEFINE's restrictions
and flushing LETREC.  Using proof by algorithm, I show that the
proposed relaxation is computable.  Enclosed is an R3RS program that
translates a simple Scheme program with extended local defines into
R3R Scheme.

Before this issue should be brought up in a Scheme meeting, the
subject of efficiency must be addressed.  I strongly suspect a fast
implementation is easy in compilers that do alpha conversion.  In
addition, since the number of local defines is usually less then 30,
graphs could be represented by an adjacency matrix, instead of a
vector of adjacency lists.  Set operations could then be fast bit
operations.

John

#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
#	eld.scm
#	make.scm
#	sc.scm
#	sets.scm
#	ts.scm
# This archive created: Mon Jul 18 10:06:17 1988
export PATH; PATH=/bin:$PATH
if test -f 'eld.scm'
then
	echo shar: will not over-write existing file "'eld.scm'"
else
cat << \SHAR_EOF > 'eld.scm'
;;; Converts extended local define Scheme to
;;; R3R Scheme with LETREC's,  LET's, and BEGIN's.

;;; John D. Ramsdell -- The MITRE Corporation -- July 1988

;;; ELD Scheme
;;; form ::= def | exp
;;; body ::= def* exp+
;;; def  ::= (DEFINE id body)
;;;       |  (DEFINE (id+) body)
;;; exp  ::= id
;;;       |  const
;;;       |  (QUOTE list)
;;;       |  (LAMBDA (id*) body)
;;;       |  (IF exp exp exp)
;;;       |  (SET! id exp)
;;;       |  (exp+)

;;; Converts ELD Scheme to R3R Scheme by analyzing the interdependency
;;; of local defines.  Finds the strong components and a topological 
;;; sort of a graph giving the interdependency.  This information is
;;; used to construct R3R Scheme replacing the extended local defines
;;; with LETREC's, LET's, and BEGIN's.

;;; To use:
;;; (eld ELD-Scheme-form) => R3R-Scheme-form

;;; Keywords.
(define define-kw 'define)
(define quote-kw 'quote)
(define lambda-kw 'lambda)
(define if-kw 'if)
(define set-kw 'set!)
(define id? symbol?)

;;; Equality predicate for set elements.
(define same? eqv?)

;;; Entry procedure.  All the excitement is in eld-body.
;;; No checks are made for syntactic correctness of ELD Scheme forms.
;;; The analysis should be done after alpha conversion.
(define (eld form)   ; => form
  (cond ((not (pair? form)) form)
        ((eq? (car form) define-kw)
         (eld-def (lambda (form free) 
                    (let ((name (cadr form)))
                      (if (element? name free)
                          (list*3 define-kw name
                                  (make-binder
                                    'letrec
                                    (list form)
                                    (list name)))
                          form)))
                  form))
        ((eld-exp (lambda (form free) form) form))))

;;; (define (name id*) body) => 
;;; (define name
;;;   (lambda (id*)
;;;     body))
(define (simplify-def def)
  (let ((pattern (cadr def)))
    (if (not (pair? pattern))
        def
        (let ((name (car pattern))
              (args (cdr pattern))
              (body (cddr def)))
          (simplify-def      ;; <- ignore this hack.
            (list define-kw
                  name
                  (list*3 lambda-kw args body)))))))

;;; All eld-* procedures below return (c form free) except
;;; eld-body and eld-seq which return (c form-seq free).
;;; free is the set of free identifiers in the form.
(define (eld-def c def)
  (let* ((def (simplify-def def))
         (name (cadr def))
         (body (cddr def)))
    (eld-body (lambda (form-seq free)
                (c (list*3 define-kw name form-seq)
                   free))  ; Note: name may be in free.
              body)))

(define (eld-exp c exp)
  (cond ((pair? exp) (eld-exp-is-pair c exp))
        ((id? exp) (c exp (singleton exp)))
        (else (c exp (empty-set)))))

(define (eld-exp-is-pair c exp)
  (let ((kw (car exp)))
    (cond ((eq? kw quote-kw) (c exp (empty-set)))
          ((eq? kw lambda-kw) (eld-exp-lambda c exp))
          ((eq? kw if-kw) (eld-exp-if c exp))
          ((eq? kw set-kw) (eld-exp-set c exp))
          (else (eld-exp-apply c exp)))))

(define (eld-exp-lambda c exp)
  (let ((args (cadr exp))
        (body (cddr exp)))
    (eld-body
      (lambda (form-seq free)
        (c (list*3 lambda-kw args form-seq)
           (set-difference free args)))
      body)))

;;; See--there is no check for three expressions.
(define (eld-exp-if c exp)
  (eld-exp-apply
    (lambda (form free)
      (c (cons (car exp) form) free))
    (cdr exp)))
         
(define eld-exp-set eld-exp-if)

(define (eld-exp-apply c exp)
  (if (null? exp)
      (c '() (empty-set))
      (eld-exp
        (lambda (exp-first free-first)
          (eld-exp-apply
            (lambda (exp-rest free-rest)
              (c (cons exp-first exp-rest)
                 (union free-first free-rest)))
            (cdr exp)))
        (car exp))))

(define eld-seq eld-exp-apply)  ; => (c form-seq free)

(define (eld-body c exp)  ; => (c form-seq free)
  (let loop ((defs '()) (exps exp))
    (let ((def (car exps)))     ; Separate def* from exp+
      (if (or (not (pair? def))
              (not (eq? (car def) define-kw)))
          (if (null? defs)
              (eld-seq c exps)  ; Speed hack.
              (eld-def&seq c defs exps))
          (loop (cons def defs) (cdr exps))))))

(define (eld-def&seq c defs seq)
  (let* ((defs (list->vector defs))
         (n (vector-length defs))
         (f (make-vector n)))   ; Vector of free sets.
    (do ((v 0 (1+ v)))
        ((>= v n))
        (eld-def
          (lambda (form free)
            (vector-set! defs v form)  ; Update defs.
            (vector-set! f v free))
          (vector-ref defs v)))
    (eld-seq                    ; Process exp+
      (lambda (form free)
        (eld-def-make-graph c defs f n form free))
      seq)))

(define (eld-def-make-graph c defs f n seq free)
  (let* ((g (make-vector n (empty-set)))
         (env (do ((v 0 (1+ v))
                   (env '() (cons 
                              (cons (cadr (vector-ref defs v)) v)
                              env)))
                  ((>= v n) env)))
         (names (map car env))  ; Assumes no duplicate names.
         (free (set-difference  ; Free to be return.
                 (do ((v 0 (1+ v))
                      (free free
                            (union free (vector-ref f v))))
                     ((>= v n) free))
                 names)))
    (do ((v 0 (1+ v)))          ; Construct graph
        ((>= v n))              ; g has an edge from v to w (v->w),
        (do ((l (vector-ref f v) (cdr l)))
            ((null? l))         ; iff the body defining w uses v.
            (let ((a (assv (car l) env)))
              (if (pair? a)
                  (vector-set! g v (adjoin (cdr a) (vector-ref g v)))))))
    (eld-analyze-graph c defs g seq free)))

(define (eld-analyze-graph c defs g seq free)
  (let loop ((ts (analyze-dependency g)) (form seq))
    (if (null? ts)              ; For each compressed component, 
        (c form free)           ; construct a binder, a LET form
        (let ((cp (car ts))     ; or a LETREC form.
               (ts (cdr ts)))
          (loop ts (construct-binder
                     (if (car cp)
                         'letrec
                         'let)
                     (cdr cp) g defs form))))))

(define (construct-binder binder cp g defs form)
  (let loop ((cp cp) (binder-defs '()))
    (if (null? cp)
        (make-binder binder binder-defs form)
        (let ((v (car cp))
              (cp (cdr cp)))
          (loop cp (cons (vector-ref defs v) binder-defs))))))

(define (make-binder binder defs form)
  `((,binder ,(map (lambda (def)
                    (let ((var (cadr def))
                          (val (cddr def)))
                      `(,var ,(seq->exp val))))
                  defs)
      ,@form)))

(define (seq->exp seq)
  (if (null? (cdr seq))
      (car seq)
      `(begin ,@seq)))

;;; list* is not part of R3RS.
(define (list*3 a b c)
  (cons a (cons b c)))
SHAR_EOF
fi # end of overwriting check
if test -f 'make.scm'
then
	echo shar: will not over-write existing file "'make.scm'"
else
cat << \SHAR_EOF > 'make.scm'
(define (make)
  (load "eld.scm")
  (load "sets.scm")
  (load "sc.scm")
  (load "ts.scm"))

(define eld-testers
  '((define (a b) b)
    (define (a b)
      (define (c w) (a w))
      (define (d x) (c w))
      (c w))
    (define (a b)
      (define (c w) (d w))
      (define (d x) (c w))
      (c w))
    (define (a b)
      (define c 3)
      (define d 2)
      (+ b c d))))

(define (eld-test)
  (for-each
    (lambda (form)
      (pp (eld form))
      (newline))
    eld-testers))
SHAR_EOF
fi # end of overwriting check
if test -f 'sc.scm'
then
	echo shar: will not over-write existing file "'sc.scm'"
else
cat << \SHAR_EOF > 'sc.scm'
;;; Algorithm to find strongly connected components of a graph.
;;; A fairly direct translation of the program given in
;;; "The Design and Analysis of Computer Algorithms", Aho, Hopcroft,
;;; and Ullman, Adison-Wesley, 1974.

;;; g is an vector containing adjacency lists.
;;; Returns a vector in which all nodes of a strong component
;;; are given in the adjacency list of one of the nodes.
(define (sc g)
  (let* ((n (vector-length g))
         (dfn (make-vector n))
         (old (make-vector n '#f))
         (lowlink (make-vector n))
         (sc (make-vector n (empty-set)))
         (count 0)
         (stack '()))
    (letrec
      ((search 
         (lambda (v)
           (vector-set! old v '#t)
           (vector-set! dfn v count)
           (vector-set! lowlink v count)
           (set! count (+ count 1))
           (set! stack (cons v stack))
           (do ((l (vector-ref g v) (cdr l)))
               ((null? l))
               (let ((w (car l)))
                 (if (not (vector-ref old w))
                     (begin
                       (search w)
                       (vector-set! lowlink v
                                    (min (vector-ref lowlink v)
                                         (vector-ref lowlink w))))
                     (if (and (< (vector-ref dfn w) (vector-ref dfn v))
                              (memv w stack))
                         (vector-set! lowlink v
                                      (min (vector-ref lowlink v)
                                           (vector-ref dfn w)))))))
           (if (= (vector-ref lowlink v)
                  (vector-ref dfn v))
               (let loop ()
                 (let ((x (car stack)))
                   (vector-set! sc v
                                (adjoin x (vector-ref sc v)))
                   (set! stack (cdr stack))
                   (if (not (= x v)) (loop))))))))
      
      (do ((v 0 (1+ v)))
          ((>= v n) sc)
          (if (not (vector-ref old v))
              (search v))))))

        
SHAR_EOF
fi # end of overwriting check
if test -f 'sets.scm'
then
	echo shar: will not over-write existing file "'sets.scm'"
else
cat << \SHAR_EOF > 'sets.scm'
;;; Sets much like those used by Guy Lewis Steele Jr.
;;; in his Rabbit compiler.

(define (element? e s)
  (and (not (null? s))
       (or (same? e (car s))
           (element? e (cdr s)))))

(define (adjoin e s)
  (if (element? e s)
      s
      (cons e s)))

(define (union s0 s1)
  (do ((s s1 (cdr s))
       (u s0 (adjoin (car s) u)))
      ((null? s) u)))

(define (intersect s0 s1)
  (cond ((null? s0) '())
        ((element? (car s0) s1)
         (cons (car s0) (intersect (cdr s0) s1)))
        (else (intersect (cdr s0) s1))))

(define (remove e s)
  (cond ((null? s) s)
        ((same? e (car s)) (cdr s))
        (else
          (let ((s0 (remove e (cdr s))))
            (if (eq? s0 (cdr s))
                s
                (cons (car s) s0))))))

(define (set-difference s0 s1)
  (do ((s s0 (cdr s))
       (d '() (if (element? (car s) s1)
                  d
                  (cons (car s) d))))
      ((null? s) d)))

(define (empty-set)
  '())

(define empty? null?)

(define (singleton e)
  (list e))

(define (singleton? s)
  (and (not (null? s))
       (null? (cdr s))))
  
SHAR_EOF
fi # end of overwriting check
if test -f 'ts.scm'
then
	echo shar: will not over-write existing file "'ts.scm'"
else
cat << \SHAR_EOF > 'ts.scm'
;;; Topological sort

;;; Takes a graph represented as a vector of adjacency lists.
;;; Returns a topological sort.  The sort is a list of components.
;;; Each component is marked with a boolean telling if the component
;;; is cyclic.  Non-cyclic components have been merged when no
;;; order is implied.
(define (analyze-dependency g)
  (ts g (sc g)))

;;; Constructs the condensed graph given the strong components.
;;; The condensed graph is the acyclic graph gotten by condensing
;;; each strong component into a single node.
(define (ts g sc)
  (let* ((n (vector-length g))
         (out (make-vector n (empty-set)))  ; The condensed graph.
         (in (make-vector n (empty-set))))  ; Condensed graph's dual.
    (do ((v 0 (1+ v)))
        ((>= v n))          ; Construct condensed graph.
        (do ((l (vector-ref sc v) (cdr l)))
            ((null? l))
            (let ((w (car l)))
              (vector-set! out v
                           (union (vector-ref out v)
                                  (vector-ref g w)))))
        (vector-set! out v
                     (set-difference (vector-ref out v)
                                     (vector-ref sc v))))
    (do ((v 0 (1+ v)))
        ((>= v n))          ; Construct dual.
        (do ((l (vector-ref out v) (cdr l)))
            ((null? l))
            (let ((w (car l)))
              (vector-set! in w
                           (union (vector-ref in w)
                                  (singleton v))))))
    (ts-bfs g sc out in n)))

;;; A breadth first search topological sort.
(define (ts-bfs g sc out in n)
  (let ((search             ; List of strong components.
          (do ((v 0 (1+ v))
               (s '() (if (empty? (vector-ref sc v))
                          s
                          (cons v s))))
              ((>= v n) s))))
    (letrec
      ((main-loop           ; Finds nodes to process on this pass.
         (lambda (search next-search is-cyclic new-ts ts)
           (if (null? search)
               (restart-bfs next-search is-cyclic new-ts ts)
               (let ((v (car search))
                     (search (cdr search)))
                 (if (and (empty? (vector-ref out v))
                          (eq? is-cyclic (cyclic? (vector-ref sc v) g)))
                     (main-loop search next-search
                                is-cyclic (cons v new-ts) ts)
                     (main-loop search (cons v next-search) 
                                is-cyclic new-ts ts))))))
       (restart-bfs         ; Processes nodes with zero out degree.
         (lambda (search is-cyclic new-ts ts)
           (let ((ts (if is-cyclic   ; Compute new ts for this pass.
                         (let loop ((ts ts) (new-ts new-ts))
                           (if (null? new-ts)
                               ts
                               (let ((v (car new-ts))
                                     (new-ts (cdr new-ts)))
                                 (loop (cons
                                         (cons is-cyclic
                                               (vector-ref sc v))
                                         ts)
                                       new-ts))))
                         (if (null? new-ts)
                             ts
                             (cons (cons is-cyclic new-ts) ts)))))
             (do ((new-ts new-ts (cdr new-ts))) ; Update condensed graph.
                 ((null? new-ts) (start-bfs search (not is-cyclic) ts))
                 (let ((v (car new-ts)))        ; ^ Switch search mode.
                   (vector-set! sc v (empty-set))
                   (do ((l (vector-ref in v) (cdr l)))
                       ((null? l))
                       (let ((w (car l)))
                         (vector-set! out w 
                                      (remove v (vector-ref out w))))))))))
       (start-bfs
         (lambda (search is-cyclic ts)
           (if (null? search)
               ts
               (main-loop search '() is-cyclic '() ts)))))
      (start-bfs search #f '()))))

(define (cyclic? cp g)         ; A component is cyclic iff
  (or (not (singleton? cp))    ; it does not have one element,
      (let ((e (car cp)))      ; or that element does not have
        (element? e (vector-ref g e)))))   ; a self-loop.
SHAR_EOF
fi # end of overwriting check
#	End of shell archive
exit 0

Received: from void (TCP 2206400236) by MC.LCS.MIT.EDU 17 Jul 88 15:50:21 EDT
Received: by VOID.AI.MIT.EDU; Sun, 17 Jul 88 15:50:13 edt
Date: Sun, 17 Jul 88 15:50:13 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8807171950.AA11762@void>
To: aab@zurich.ai.mit.edu
Cc: willc@tekchips.crl.tek.com, RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: Andrew A. Berlin's message of Sat, 16 Jul 88 23:43:20 edt <8807170343.AA04677@caddr>
Subject: agenda
Reply-To: jar@zurich.ai.mit.edu

   Date: Sat, 16 Jul 88 23:43:20 edt
   From: aab@CADDR.AI.MIT.EDU (Andrew A. Berlin)

   ... Could you please elaborate on the reasons for this suggested change?

Details about almost all of the proposals can be found in the packet
that I sent out.  Copies are in my office, and sources are in
zurich:/zu/jar/r4-agenda/packet.tex.  Or check the archives for the
mailing list to find the original message.


Received: from caddr (TCP 2206400243) by MC.LCS.MIT.EDU 16 Jul 88 23:42:45 EDT
Received: by CADDR.AI.MIT.EDU; Sat, 16 Jul 88 23:43:20 edt
Date: Sat, 16 Jul 88 23:43:20 edt
From: aab@CADDR.AI.MIT.EDU (Andrew A. Berlin)
Message-Id: <8807170343.AA04677@caddr>
To: willc@tekchips.crl
Cc: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl
In-Reply-To: willc@tekchips.crl's message of 13 Jul 88 17:34:06 PDT (Wed) <8807140034.AA10164@tekchips.CRL.TEK.COM>
Subject: RE: agenda
Reply-To: aab@zurich.ai.mit.edu


    RENAME SET! TO SET.

    RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR.  Issue:
    non-destructive versions make sense even though they're not in the
    report.

Could you please elaborate on the reasons for this suggested change?

How do people feel about this?

- Andy

Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Jul 88 07:48:30 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
	id AA07927; Fri, 15 Jul 88 07:47:31 EDT
Posted-Date: Fri, 15 Jul 88 07:47:43 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
	id AA15914; Fri, 15 Jul 88 07:47:43 EDT
Date: Fri, 15 Jul 88 07:47:43 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807151147.AA15914@huxley.sun.uucp>
To: RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 13 Jul 88 17:34:06 PDT (Wed) <8807140034.AA10164@tekchips.CRL.TEK.COM>
Subject: Replace LETREC with "relaxed" internal DEFINES.

From the agenda:
>RELAX THE LETREC RESTRICTION.  Require implementations to find
>an order that works, if any does.  Issue:  not computable?

I think the whole point of relaxing the LETREC restrictions was to
allow the replacement of LETREC's and many LET's with local DEFINE's.
If the strong components of some local DEFINE's dependency graph is
topologically sorted, an interpreter or compiler can generate the best
combination of LETREC's and LET's.  Programmers would then be freed of
having to think about current large distinction between local
definitions and top level definitions.  The issue is:

RELAX LOCAL DEFINES RESTRICTIONS AND FLUSH LETREC.  Require
implementations to treat local DEFINE's as the best combination of
LET's and LETREC's.

John

PS. I would like to see file compilers treat top level defines just as
I suggest local defines be treated.  Why should the order be so
important within files?


Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Jul 88 23:34:06 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab26383; 14 Jul 88 23:17 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa09069; 14 Jul 88 23:06 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA02215; Thu, 14 Jul 88 18:50:19 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
	id AA04054; Thu, 14 Jul 88 18:52:34 PDT
Message-Id: <8807150152.AA04054@tekchips.CRL.TEK.COM>
To: RRRS-AUTHORS@mc.lcs.mit.edu
Cc: willc@tekchips.crl
Subject: time & place of R*RS authors' meeting
Date: 14 Jul 88 18:52:32 PDT (Thu)
From: willc@tekchips.crl

The R*RS authors' meeting will begin at 8:45 am on Sunday, 24 July,
in the Maybird room of Cliff Lodge (the LFP hotel).  We have the room
until 6 o'clock that evening.  An overhead projector and screen will
be available.  Thirty two people have indicated they will come.

Please note that this meeting is distinct from the IEEE standards
meeting, which will take place Wednesday afternoon.

See you at Snowbird,
Will

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Jul 88 23:13:44 EDT
Date: Thu, 14 Jul 88 23:16:17 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Proposals compendium
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <412510.880714.JAR@AI.AI.MIT.EDU>

I have mailed hardcopy of a document called "Proposals for a Revised^4
Scheme Report" to everyone who sent their address to Will.  The document
is organized around Will's agenda, and consists almost entirely of
extracts from messages that have appeared on this list.

I also included in the mailing two other documents: (1) edits made to
the numbers and syntax sections of the R^3 report by an ad hoc numbers
committee following last summer's meeting, and (2) the "syntactic
closures" paper by Alan Bawden and myself.  The latter is for
informational purposes only and does not constitute a proposal for
extending the language.


Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Jul 88 18:24:04 EDT
Received: from relay2.cs.net by RELAY.CS.NET id an22846; 14 Jul 88 17:45 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa07444; 14 Jul 88 17:33 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA29468; Wed, 13 Jul 88 17:32:54 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
	id AA10164; Wed, 13 Jul 88 17:34:08 PDT
Message-Id: <8807140034.AA10164@tekchips.CRL.TEK.COM>
To: RRRS-AUTHORS@mc.lcs.mit.edu
Cc: willc@tekchips.crl
Subject: agenda
Date: 13 Jul 88 17:34:06 PDT (Wed)
From: willc@tekchips.crl

Agenda for the RRRS meeting on Sunday, 24 July.

The agenda is divided into four parts.  The first part consists of relatively
noncontroversial proposals whose adoption in some form is recommended by the
agenda committee.  The agenda committee makes no recommendations concerning
the rest of the agenda.

The second part of the agenda considers general questions of policy.  The
third part consists of major proposals.  Some of these may not be ready for
adoption but would benefit from discussion.  The fourth part consists of all
remaining proposals.


**PART 1: CLEANUPS**

RESERVED WORDS AND PORTABLE CODE.  Require that implementations
provide some way for programmers to work in a syntactic environment
containing no reserved words other than those found in the report,
without requiring that this be the default syntactic environment.

DISJOINTNESS OF TYPES.  Require that the following sets of objects
be disjoint:  booleans, pairs, symbols, numbers, characters, strings,
vectors, procedures.  Issue: add the singleton set containing the
empty list to the list.  Issue: remove characters from the list.
Issue: add promises to the list, or flush force and delay altogether
(see **OTHER PROPOSALS**).

ELIMINATE NIL, T.  Remove nil and t from the report.

EQV?.  Clean up the specification of eqv?, removing the requirement
that it be true of two empty strings or empty vectors.

DUPLICATE FORMALS ARE IN ERROR.  The list of formal variables in
lambda, let, letrec, and do (but not let*) should not contain
duplications.  E.g. (lambda (x y x) ...) is an error.  In the case
of named let, the formals in the initial bindings list should be
distinct, but it is ok (albeit useless) for the "name" to duplicate
a formal.  E.g. (let foo ((x 1) (foo 2)) ...) is legal.

CHANGE WORDING OF LETREC RESTRICTION.  From "...without referring
to the value of any <variable>" to "...without referring to the
value or location of any variable".  Example:

  (letrec ((wanna-be-a-doctor    'doctor)
           (imagine-my-surprise! (begin
                                  (set! wanna-be-a-doctor 'nurse)
                                  'zowie)))
    wanna-be-a-doctor)

CLARIFY WORDING OF LETREC.  Add the word "ALL" as follows:
"...in a letrec expression, ALL the bindings are in effect while
their initial values are being computed..."

CLARIFY MEANING OF QUASIQUOTE.  As in Pavel Curtis's proposal.

CLARIFY STATUS OF CI.  Though CI is described as a suffix,
it is generally just embedded.

CLARIFY THE SPECIFICATION OF TRUNCATE.  Specify the sign of
the result, and specify the absolute value of the result.

IMPROVE THE DISCUSSION OF EXACTNESS AND INEXACTNESS.  As in
R^3.5RS.

CHANGE THE SYNTAX OF NUMBERS.  As in R^3.5RS:  use the exponent
marker to indicate the precision of inexact numbers, and use
3+i4, 3-i4, 3+i, 3-i, +i4, -i4, +i, -i, and 3@3.14159265 for
complex numbers.  Issue: 3+4i would be more in keeping with
common mathmatical practice.

CLARIFY THE STATUS OF EXPONENTS.  As in R^3.5RS:  numbers that
contain decimal points or exponents must be in decimal radix.

EXPONENTS ILLEGAL IN FRACTIONS.  As in R^3.5RS: 3/4e5 is not
legal.

EXACTNESS AND INEXACTNESS OF CONSTANTS.  Constants that contain
no explicit exactness prefix are inexact if they contain any of
the following:

  an explicit inexactness prefix
  an at-sign indicating polar representation
  a decimal point
  a sharp sign indicating a "don't care" digit, as in 123##

A constant may also be inexact if it contains a negative exponent;
this is implementation-dependent.  Otherwise the constant is exact.

  Issue:  3@0     (inexact by above rules)
  Issue:  1e5     (exact by above rules)
  Issue:  1e-5    (implementation-dependent by above rules)


**PART 2: POLICY ISSUES**

FLUSH OPTIONAL FEATURES.  Do away with the distinction between
essential and optional features.  In effect, make everything
essential.  Issue: some optional features should be dropped rather
than made essential; which?

MAKE PROCEDURES MORE REGULAR.  Add vector-copy, list-copy,
list-fill!, list-set!, (make-list k); or remove procedures
to make them more regular across the different kinds of
sequences.  Issue:  what's the policy?  Issue:  generic
copiers, fillers, etc.  Issue: optional or essential?

UNDERSPECIFICATION.  What kinds of underspecification are
desirable?  What kinds are undesirable?


**PART 3: MAJOR PROPOSALS**

MACROS.  No complete proposal is ready for consideration.  The
macro and extend-syntax syntaxes have been proposed as least
common denominator(s) to tide us over until we have a real macro
proposal.

MODULES.  Pavel Curtis, Jonathan Rees, and John Ramsdell have
sketched proposals, but no complete proposals are ready for
consideration.  The next four proposals are related to this.

REPLACE LOAD WITH INCLUDE.  The load procedure is convenient for
interactive program development, but its dependence on an object
with state (the external file system) makes it less satisfactory
than include would be for describing complete programs.
Presumably implementations would retain load as part of their
programming environment even if it were replaced by include in
the report.  Issue:  An alternative is to change the meaning of
load in the report.  Issue:  Include also depends on an external
file system; the only difference is that the dependency is removed
at compile time rather than run time.

FIRST CLASS ENVIRONMENTS.  In my opinion, no proposal for
environments remains on the table.  A proposal could be built
around make-environment, the-environment, build-environment,
Guzowski's with, or Pavel's recently withdrawn proposal.

ADD EVAL.  Add eval to section 6.10.4.  Issue: one or two arguments?
If two, how do you get an appropriate second argument?

ADD SECOND ARGUMENT TO LOAD.  If eval is added and takes a second
argument, then shouldn't a second argument should be added to load
also?

ADD LAMBDA*.  Adopt the Hieb/Dybvig proposal for procedures that
dispatch on the number of arguments they are given, for allowing
multiple values to be stored in variables, and for the & syntax.
This proposal is an alternative to the next two proposals.

MULTIPLE RETURN VALUES.  Add optional procedures values and
with-values such that (values x1 ...) returns values x1 ... and
(with-values thunk proc) calls proc on the values returned by
thunk.  Issue: what do continuations that currently expect one
return value do when given zero values or more than one value?
The most popular answers are:

  a.  It is an error.
  b.  Ignore extra values; it is an error if there are no return
      values.
  c.  Ignore extra values; the continuation gets an unspecified
      value if there are no return values.
  d.  Ignore extra values; the continuation gets #f if there are
      no return values.

OPTIONAL ARGUMENTS.  Add an optional #!optional syntax to lambda
expressions to support optional arguments:

  (lambda (x #!optional y z . w) ...)

If not supplied, y and z are bound to new locations holding a
special default object.  Add the procedure default-object? so that
(default-object? y) is true if y is not supplied.  It would be
possible to pass the default object as an actual argument, thereby
making it possible to obtain the default for y while specifying z
explicitly.

RECORD OBJECTS.  Jonathan's proposal:

  make-record-type
  record-constructor
  record-predicate
  record-accessor
  record-updater

  Issue:  If the object returned by make-record-type isn't a type
  but a "descriptor", then maybe the name is wrong.

  Issue:  what about record-copier?

  Issue:  inheritance.

  Issue:  something resembling type-of.

  Issue:  Initialization of all fields, positionally, rather than
  initialization of selected fields by name.

  Issue:  Optional?


**PART 4: OTHER PROPOSALS**

CHANGE WORDING OF SET! RESTRICTION.  From "<Variable> must be
bound in some region enclosing the set! expression or at top
level" to "<Variable> must be bound in an enclosing lexical
environment".  Issue: need examples of code that illustrate
the intended differences between the two wordings.

FORMAL SEMANTICS FOR NUMERIC CONSTANTS.  As proposed by Clinger,
who doesn't think it is necessary.

ELIMINATE DO.  Remove do from the language.

ELIMINATE NAMED LET.  Remove named let from the language.

ELIMINATE =>.  Remove the => notation from the language.

ELIMINATE CASE.  Remove case from the language.

ELIMINATE FORCE AND DELAY.  Or make promises disjoint from other
types.

ELIMINATE LAST-PAIR.  Remove last-pair from the language.

ELIMINATE NUMERIC FORMATS.  Eliminate (or redesign or simplify)
the format arguments to number->string.

ELIMINATE CALL-WITH-CURRENT-CONTINUATION.  Remove
call-with-current-continuation because it makes programs hard to
understand.

DEFINE WITH NO EXPRESSION.  Optionally allow (define x) for top level
definitions only.  Issue: why not for internal definitions?  Issue:
If it becomes available for internal definitions, then it should also
be available for letrec, let, let*, named let (?), and do (??).

ADD CALL.  Add essential syntax: (call proc arg1 ...).

ADD STATIC.  Add essential syntax: (static id).

PEEK-CHAR.  Add a peek-char procedure.  Issue: essential?

ADD EQ-HASH, EQV-HASH.  (eq? x y) implies (= (eq-hash x) (eq-hash y)),
and (eqv? x y) implies (= (eqv-hash x) (eqv-hash y)).  Implementations
are encouraged to make the converse as probable as possible.

ADD DAYS-AFTER-J2000.0.

VALUE RETURNED BY ONE-ARMED IF, COND.  Specify that (if E0 E1) returns
#f if E0 is false, and that (cond ...) returns #f if no clauses apply.

VALUES RETURNED BY SIDE EFFECTS.  Change the semantics of
(set! x e), (set-car! x e), (write e p), et cetera, so that
they return the value of e.  Issue: why not return #!unspecified?

LEFT TO RIGHT EVALUATION OF ARGUMENTS.  Change the semantics of
procedure calls so that expressions are evaluated from left to
right.

LEFT TO RIGHT EVALUATION OF DEFINITIONS.  Change the semantics
of internal definitions so that they are evaluated from left to
right.  Issue: do the same for letrec?

CHANGE THE SPECIFICATION OF AND.  Change and so it always returns
#t or #f.  Issue:  the last position of an and becomes non-tail-
recursive.  Issue:  If this proposal is not adopted, must and
return the first false value it sees, or can it simply return #f?

RENAME CHARACTER COMPARISON PREDICATES.  Change char=? etc to
char= etc.

RENAME SET! TO SET.

RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR.  Issue:
non-destructive versions make sense even though they're not in the
report.

RENAME CHAR-READY? TO READ-CHAR-READY?.  Issue: name:
READY-TO-READ-CHAR?  Issue: replace instead
with read-char? (TYI-NO-HANG)?

RELAX THE LETREC RESTRICTION.  Require implementations to find
an order that works, if any does.  Issue:  not computable?

DON'T SPECIFY WHETHER THE EMPTY LIST COUNTS AS TRUE OR FALSE.