[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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?