EQ? again, already

[Jonathan A Rees <JAR@MIT-MC.ARPA>]

    Date: Fri, 13 Dec 85 16:31 EST
    From: Guy Steele <gls at THINK-AQUINAS.ARPA>

    I feel it is a mild pity that RRRS has made this same mistake.

If EQ? were banished to the realm of "implementation-dependent" and
satisfying few portable axioms (e.g. it could look at the machine state
when given two EQV? numbers), and EQV? were considered the portable
equality primitive, what would you have it do with procedures?

More importantly, I would like to see evaluation of LAMBDA-expressions
not be a side-effect, but not only is a contradictory assumption wired
into Abelson & Sussman's book (according to Sussman), the problem is
undecidable if by equality you mean what compilers would like equality
to mean, that is extensional equality ("f computes the same return value
and machine state as g given the same input arguments and machine
state").  Which would you prefer:
  (a) to define EQV? to "be an error" when both arguments are procedures
      (this implies that implementations would be encouraged to signal
      errors, of course),
  (b) to define LAMBDA to be a side-effect,
  (c) to rule out optimizations which would inhibit "intensional"
      comparison of procedures, or
  (d) make EQV? to be implementation-dependent (and thus put it in the
      same flea-bitten bag as EQ?)?  I think those are the only alternatives.

Actually, now that I think of it, option (c), intensional procedure
comparison, could be made to work, conceivably.  E.g. EQV? on two
procedures could use EQV? to compare bignums representing some canonical
form of the source (or object?) code (alpha- and maybe beta-converted to
some sort of normal form, and maybe other things) and the presumably
cons-cell-like cells which hold values of variables.  Then indeed

(EQV? (LAMBDA (X) (LIST X Z)) (LAMBDA (Y) (LIST Y Z)))

would be defined to return true, and we could intern object code, do
CSE, and so on.  I haven't though about this possibility, but I suspect
it would be very complicated to implement, and would inhibit some
important optimizations.

I echo my previous simple request (to which no one has replied - I guess
that everyone agrees): permit implementations of EQV? to signal an error
when given arguments that are both procedures.