substring-vector-null-fill!, colitis, etc.

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

Here are changes I've made at the requests of people too numerous to
mention (I wish I could acknowledge everyone individually, but time
presses):

I've flushed SUBSTRING-FILL! and STRING-NULL?.  If STRING-NULL? is
retained then VECTOR-NULL?  should be added.  These are both in a
somewhat different class than NULL? since NULL? is often used to
terminate recusrions but STRING- and VECTOR-NULL? aren't.

It's now clearly an error to alter an object returned as the value of a
constant expression, e.g. (string-set! "foo" 1 #\x) and (set-car! '(a b) 'c)
are errors.

The list of extended alphabetics has been moved from "other notations"
to "identifiers".

I'll try to flush the garbage about immutability from the eqv? section,
and leave the question of (eq? '(a) '(a)) unbreached.

Small organizational error fixed: the nonterminal <sequence expression>
is gone, and (begin <sequence>) is now an alternative right-hand side
for <derived expression>.

The equation defining exponentiation has been repaired.

-----
Questions:

- Advice sought on what to do about the grammar for COND and CASE.  In
question is the treatment of non-final ELSE clauses.  Two people have
mentioned that as it stands the grammar is too liberal.  Should I change
it so that there are two rules for each, viz.

  <derived expression>  -->  ...
     | (cond <cond clause>+)
     | (cond <cond clause>* (else <sequence>))
     | ...
     | (case <key> <case clause>+)
     | (case <key> <case clause>* (else <sequence>))
     | ...

?  Seems to me it's not grave if it's left as is, since the text
explains that actually the else clause should come at the end.

- I can sort of see why VECTOR-FILL! exists (it has to exist internally in
any case, in order to support the optional argument), but symmetry
considerations would suggest either flushing it or adding STRING-FILL!.
Opinions?  No change here so far.

- I don't think I have time to change number syntax, although I think
specifying default exactness on input is easier, since I can just copy
text from Will's messages.  I have two small arguments with Will's rule
which says that 1e3 is exact.  One is that this makes exactness somewhat
tricky to determine -- you have to be able to count in order to
determine whether a string represents an exact number or not.  I prefer
the simpler rurule which says that the presence of an exponent marker
makes the number inexact by default.  The second argument stems from CL
compatibility concerns: if Scheme's exact integers are identical to CL's
integers, and Scheme's inexact (rational) flonums are identical to CL's
flonums, then making 1e3 represent an exact number would be an
incompatibility between Scheme and CL.  This correspondence seems
natural to me.  I'd like to hear arguments in favor of Will's rule.

- I'm inclined to demote colon from alphabetic to unspecified (like \ and
|), although I'd like the case to be made more clearly.  I would really
hate to see someone add Common-Lisp-like read-time packaging to any
Scheme, so I don't admit that as a good reason for this change, although
if foo:bar read in the same as (access bar foo) that wouldn't be so bad.
However, I'm primarily a Scheme-in-Common-Lisp user myself these days,
and the implementation and its integration into the host CL would indeed
be cleaner if colon weren't extended alphabetic, so I DO see CL
compatibility as a good reason for the change.

On the side of an alphabetic colon, I should mention that the
moderate-sized community of pro-Scheme people raised on Riesbeck,
Charniak, and/or McDermott's book(s), or otherwise immersed in Yale AI
Lisp culture, use colon pretty heavily as an alphabetic character.

Also, there are some other alternatives for CL <--> Scheme communication:

    - A way to coerce packages to environments, so e.g. if you want
    Lisp's ELT function you can say (access elt lisp-package).  This is
    what CLSCH does now.

    - A procedure which makes Lisp symbols, e.g. (make-lisp-symbol 'lisp
    'elt).

    - A reader syntax such as #[Lisp-symbol lisp elt] or #>Lisp>elt.

None of these is quite as attractive as just saying lisp:elt.

I'll wait for more comments, then flip a coin.

- Jonathan