S&I's idea of EQ?

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

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

    When last I heard, MIT Scheme on the HP 9836 was using a simple stop and
    copy collector

MIT Scheme uses a somewhat modified stop and copy garbage collector
which originally increased performance significantly.  I have no
current figures.  On average code (compiled or not) the overhead
caused by the garbage collector is at worst 10% (% of time spent
garbage collecting vs. total time).  I feel that this is completely
acceptable.  Some of us (GJS in particular) don't believe very much on
optimizing consing, but rather in (very) large memories and very fast
garbage collectors.

    A few months ago I proposed the following consistent semantics:  if eq?
    is given procedures as arguments, it returns #!true if the associated
    locations are the same.  If the associated locations are different but
    the "functional parts" (E* --> K --> C) are equal, then eq? may return
    #!true or #!false at its whim.  If the functional parts are not equal,
    then eq? must return #!false.

I'm not sure a I understand your domain equation, and I may be missing
something, but... 

1) Do you mean that an implementation might choose always to return
#!true on 2 different "closings" of the same lambda expression?
If so, I consider this proposal unacceptable since 2 different
invocations of

(define (make-cell contents)
  (define (setter new-value)
    (set! contents new-value))
  (lambda (message)
    (cond ((eq? message 'CONTENTS) contents)
	  ((eq? message 'SET-CONTENTS!) setter)
	  (else (error "Cell: Unknown request"))))))

would result in EQ? objects which are clearly distinguishable by other means.

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.