Scheme BNF

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

    Date: Thu, 27 Mar 1986  03:27 EST
    From: CPH%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU

    A fine point I would like to make is that RRRS is careful to allow the
    possibility of immutable strings.  In this case I think that EQV?
    makes sense on strings, so that (sigh) an even more complicated syntax
    would be needed which took into account that possibility.

I agree with you, but there are further ramifications.  People have said
that EQ? and EQV? should agree on everything besides numbers and
characters.  If this constraint is maintained, than EQ? must also return
true for immutable strings with identical contents.  But this could make
EQ? expensive, which, it seems to me, would defeat the point of making
it different from EQV?.  Another issue is whether EQV? should compare
immutable data in general.  I would say it should.  I guess I would
propose for EQ? to act on immutable data the same way it does on
procedures, remembering where they came from but maybe returning false
for things that are operationally equivalent.  EQV?  would test for true
operational equivalence in the case of immutable data.

    On the other hand, I like the idea of using EQUAL? and I agree that it
    is easy to make efficient.

Like I say, I don't care.

    However, just to complicate things, I'll mention something about CASE
    that has bothered me when I have tried to use it.  I sometimes have
    found that I am doing something of this kind:

    (COND ((EQ? X 'FOO) ...)
          ((EQ? X BAR) ...)
          ((EQ? X 'BAZ) ...)
          ...)

    where one of the keywords I am matching against has been parameterized
    for one reason or another, and this forces me to use COND rather than
    CASE.  Has anyone else run into this problem?  Is it interesting
    enough to consider modifying CASE?

Yes.  No.  I like the fact that CASE is minimal.  I think that if we try
to generalize it or come up with other constructs, we'll never be able
to agree on what to do, and the manual will get longer.  I say you
should either use COND, a more featureful language than Scheme.

    Actually, MIT Scheme has a consistent meaning for both of these, which
    is that the variable in question is bound but not assigned.  Such
    variables are only useful in the presence of assignments, and it is an
    error to refer to one between the time that it is bound and when it is
    assigned.  I suspect that some will find this offensive, although
    personally I find it preferable to other alternatives that I have seen
    for describing this particular state.  So I'm just pointing it out for
    general interest.

This is what T does too, although it doesn't detect the error.  What do
other people think?  This would have to be a new documented feature of
LET; would it have to be essential?