Re: S&I's idea of EQ?

[willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA]

    As numbers demonstrate, it is both possible and useful to manipulate
    objects without side effecting them.  As I recall, S&ICP uses only
    the make-environment and eval operations on environments, neither of
    which mutates an environment.  I can imagine many other
    non-side-effecting operations on environments, such as:

  What happens to (eval '(define x 4) <some-environment>)?

You're quite right; the interpreter in chapter 4 of S&ICP side effects
the environment if x is not already bound.  I don't have to like it,
but that's what it does.  The only way I see to avoid side effects to
environments and also remain consistent with S&ICP and with RRRS is
by arranging never to have any unbound variables.  I don't have to
like that either, but that's what I does.

    1) Do you mean that an implementation might choose always to return
    #!true on 2 different "closings" of the same lambda expression?

No, eq? gets to say #!true only if the procedures have identical
behavior aside from the fact that they are associated with distinct
locations.  The procedure domain (E* --> K --> C) is the set
of continuous maps from arguments to expression continuations to command
continuations; despite this imposing explanation, an element of the
procedure domain is nothing more than the behavior of a procedure in
the intuitively simple model.  Thus eq? procedures are behaviorally
indistinguishable.

    2) I'm confused by your proposal.  I think naive users would be
    confused also.  If models become too complicated, the language becomes
    intractable.  If the mathematics of the intuitively simple model are
    less elegant, that may imply that the mathematic representation is not
    adequate.  In case of conflict, I will usually choose the intuitively
    simple model since a new representation better suited to it may appear
    tomorrow.  One of the main reasons why Scheme has become popular (I
    think) is that it is easy to learn.  This proposal would complicate it
    unnecessarily.

Truly naive users shouldn't be using eq? on anything but symbols.
(Some would say that truly sophisticated users don't need to use
eq? on anything but symbols.  I haven't yet reached that stage.)

The intuitively simple model doesn't attach locations to procedures,
and allows us to explain that eq? doesn't work on procedures because
equality of procedures is computationally undecidable.  That model
has been rejected, however, so we have to explain that eq? kind of
works on procedures, but is not entirely reliable because equality
of procedures is computationally undecidable.  Instead of comparing
the procedures to see if they are equal, eq? looks at the computational
history of the procedures and returns #!true if they were created at
the same instant in time.

At this point we should admit that eq? is an example of bad language
design, but that we are stuck with it for historical reasons.  We've
probably had to apologize for eq? earlier in connection with numbers,
so this is no big deal.

Up to now I've probably been saying more or less what's said in 6.001.
Some users will then ask, "Isn't that [the time at which a procedure
is created] implementation-dependent?" and I then say "Yes, it's
just like eq? on numbers.".  I don't know what people say in 6.001,
but I suspect it's a lot more complicated than what I say.

The answer can't be to give the user an interpreter, because she
would then ask--assuming she is no longer naive--"But isn't the
interpreter just a particular implementation?" and she would be
right.

Users should have a healthy disrespect for the programming languages
they are forced to use, so there's no point in pretending that Scheme
makes sense in all its dark corners.  You should hear me trying to help
people understand Common Lisp.

Peace, Will