S&I's idea of EQ?

[Bill Rozas <JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu>]

    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.)

What about pairs and other mutable objects?  Procedures with state are
effectively mutable (some more opaquely than others of course) and
this is the main reason for desiring EQ? to work on them.

    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.

This is the reason JAR and I agreed that it was acceptable to both if
EQ? was optional as long as if present it had the "traditional"
properties (implying no coalescing or splitting).  Unfortunately other
people thought that this was not a viable answer.

There is a difference with numbers.  There is a well defined predicate
(= or =?) which is appropriate, so eq? is superfluous and its
behaviour can well be implementation dependent.  On the other hand,
procedures can have internal state and there is no other predicate
defined on them.

    The intuitively simple model doesn't attach locations to procedures,

I disagree.  The moment that internal state appears, it becomes
apparent that there are locations associated with procedures.

    and allows us to explain that eq? doesn't work on procedures because
    equality of procedures is computationally undecidable.  

This is only slightly worse than the problem with equal? and
circularity.  It seems to me that you are trying to give eq? a sort of
"equal?ish" semantics for procedures, but this would be inconsistent
with its behaviour on other types.

							     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.

If coalescing is allowed (by default) this instant of time becomes
something controlled by the compiler and not the programmer.  My
understanding of programs (and I believe of many other people around
here) comes from having a detailed and accurate model of their
execution.  This optimization violates this understanding in a
fundamental way, and would make it very confusing to me.  Particularly
so since I would have no way in general of bypassing this optimization
and forcing the order that I would like.  

It seems to me that the question of whether coalescing is allowed is
only a matter of efficiency.  I'm perfectly happy to have it as an
explicit optimization to be allowed by the user, but it seems
excesive to allow it by default.  Again, why do people object to a
declaration to this purpose?