Re: EQ? non-essential?

[David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>]

Here are some comments on recently raised issues...

(1) I agree with JAR that OBJECT-HASH should be flushed.

(2) I still believe strongly that EQ? should amount to a pointer test
and that the standard should specify the domain over which it is
defined---symbols, booleans, (), and mutable objects (pairs, vectors,
strings, and ports).  It should be undefined (implementation-dependent
but not an error) for numbers, characters, closures, and
continuations.

Bert asks whether the optimization this allows is worth the loss of
the ability to compare procedures which represent abstract data.  I
have to say yes for two reasons.  First, some other predicate than EQ?
makes better sense for such tests.  Second, the inhibition on the
optimizing compiler is pretty strong since the EQ? test may not be
lexically visible.  The compiler can't always know when it is safe to
split and when it isn't.  Thus, I oppose the idea that (EQ? X X)
should always be true.

I also disagree strongly with JAR's latest suggestion that EQ? be made
non-essential.  Doing so doesn't solve the problem, it just passes the
buck!

  >The effect of this is that while all existing implementations would stay
  >the same and implement EQ? as always, [...]

Not so!  I've explained why I want EQ? and why ``implementing EQ? as
always'' is inconsistent with the semantics that (EQ? X X) ==> #!TRUE
when you have an optimizing compiler.

(3) I agree with JAR and others that EQV? should be independent of the
implementation.  As I understand it, this amounts to saying the use of
EQV? is an error except for a specified domain.  My previous position
was that it should be implementation-dependent over all but the
(same?) domain.  I subscribe to the statement ``(EQ? X Y) implies
(EQV? X Y) whenever (EQV? X Y) is defined.''  I'd like to see EQV?
extend EQ? to encompass exact numbers and characters but not closures
and continuations.

(4) Ramsdell has raised the notion that (BEGIN ...) is redundant with
(LET () ...).  This is not true for those of us that support the
MIT-style embedded DEFINE and first-class environments.

Regards,
David Bartley
-------