[Postmaster@SCRC-STONY-BROOK.ARPA: Unable to deliver letter]

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

    [GLS -- This went to RRRS-AUTHORS and was explicitly CC'd to you but didn't
     succeed in sending directly to you so I'm retrying; you may have
     seen it already on RRRS-AUTHORS, but in case that failed, too, I'm
     risking redundancy. -kmp]

    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.


I agree with you in all these details.
--Guy