[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Anyone who wants to receive a copy of the "Revised^3 Report on the
Algorithmic Language Scheme" should make sure that I have his or her US
mail address.  I'll also make the LaTeX sources available via Internet
FTP.  I'm aiming to get it to SIGPLAN by May 1 so it can be in the July
issue, but somehow I have managed to misplace a week or two (illness &
general procrastination) so there is beginning to be a shadow of a doubt
on this proposition, since this gives practically no time for me to get
everyone's comments on the draft.  I'll mail out a draft as soon as I
can (but not immediately) and we'll see what happens.

It's in two-column format and is currently about 38 pages long (only a
little more than twice the size of the Algol 60 report!), including
index, formal semantics, and formal syntax (each of which is 2 pages).

Here are a few more little editorial decisions.  Please let me know
if you have serious objections.  I don't believe any of the ones not
previously discussed should matter much to anyone in any practical
sense, and nearly all of them serve to shorten and simplify the report.

  - Rest-argument lists are always freshly consed (semantically speaking).
    [All h*** breaks loose if not.]
  - An ELSE clause must be last in a COND or CASE.  [If implementations
    want to allow it elsewhere that's fine, but why should arbitrary
    position be essential?]
  - (ELSE) isn't a legal clause.  [If it is, what does it return, and why?]
  - (COND) and (CASE x) are syntactically legal expressions.  [No one
    objected to this liberalization when I raised the question before.]
  - (BEGIN) and (LAMBDA (X)) are not necessarily syntactically legal.
    [Several people objected to this extension.]
  - CASE selectors must all be distinct.  [This is as in Common Lisp;
    it assists error checking; and it means nothing has to be said about
    the order in which clauses are processed.]
  - It's not specified what happens if the constants in a CASE are
    objects other than numbers, symbols, characters, or booleans.
    [This allows implementations to decide for themselves what
    happens in other situations - EQV?, EQUAL?, etc.]
  - BOOLEAN? is a new essential procedure.  [For symmetry with other type
    predicates.  I didn't ask previously whether or not it should be
    essential; I hope it's OK if it is.]
  - EQ? and EQV? must both return true if their arguments are both
    empty strings or both empty vectors.  [I believe that this is
    implicit in the RRRS.  I guess making it explicit might require
    implementations which don't already do so to special case
    (MAKE-STRING 0) and (MAKE-VECTOR 0) -- is that OK?  If not, then the
    documentation for EQ? and EQV? has to have yet another special case
    in it (since zero-length vectors aren't operationally distinguishable
    from each other), and I'll have to add yet another implementation
    rationale -- ugh.  Also, if (MAKE-STRING 0) and (MAKE-VECTOR 0) are
    REQUIRED to return new objects, then the formal semantics becomes
    significantly hairier.]

The RRRS says nothing at all about whether the result of APPEND sharing
structure with its arguments.  Common Lisp says explicitly that all
arguments but the last are copied, and the last one never is.  I think
this is wrong, and maybe incompatible with existing implementations.  T
permits sharing (not clobbering) whenever that makes sense, e.g.
      (let ((x (list 1 2)))
	(eq? x (cdr (append '(a) x '() '()))))
might be true.  Is it OK if I make this explicitly OK?

What about (let ((x (list 'a))) (eq? x (reverse x))) ?