EQ? and procedures, numbers, etc

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

Hmm, let me pose a few concrete examples to test that you and I agree.

You called this splitting:

 [1] (LET ((X C) (Y C))
       (EQ? X Y))

You and I seem to agree that evaluating this expression should always
yield true. Further, I suggest that the following are also in the same 
category and assume that we both agree that these should -always- return 
true as well:

 [1a] (LET ((F (LAMBDA () C)))
        (EQ? (F) (F)))

 [1b] (LET ((F (LAMBDA () '(ANY EXPRESSION))))
        (EQ? (F) (F)))

You called this coalescing:

 [2] (LET ((F (LAMBDA () (LAMBDA () 3))))
       (EQ? (F) (F)))

I agree with you that it is reasonable for either of {true,false} to be
returned from evaluating this. I suggest that the following are special
cases of the same situation, and that it may not be possible to predict
which of {true,false} will be returned:

 [2a] (LET ((X '(ANY EXPRESSION))
	    (Y '(ANY EXPRESSION)))
	(EQ? X Y))

 [2b] (LET ((F (LAMBDA () '(ANY EXPRESSION)))
	    (G (LAMBDA () '(ANY EXPRESSION))))
	(EQ? (F) (G)))

Among other things, 2b is important because of code constructed by
expressions like:
 `(LET ((F (LAMBDA () ',EXP))
	(G (LAMBDA () ',EXP)))
    (EQ? (F) (G)))
We would like to constrain the semantics of the resulting expression to not
be perturbed by first writing the expression to an intermediate file and
then re-reading it.

Put another way -- with the exception of objects like symbols (which are
intentionally interned), sharing of memory should not affect the semantics
of an expression (though it may affect its perceived behavior). On the
other hand, certain identifiable patterns of data flow should be defined
to preserve sharing in a well-defined way, in order to ease certain 
programming tasks and also (for not reasons that are not unrelated) to 
allow various theorems, transformations, proofs, and optimizations to be
conveniently written about those patterns.