Multiple LAMBDA evaluations

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

    Date: 20 Nov 1985 1825-CST
    From: David Bartley <Bartley%CSL60%ti-csl.csnet at CSNET-RELAY.ARPA>

    (1) Are issues like the following best raised in the general Scheme
        community (e.g., SCHEME@MIT-MC) or here among the RRRS authors?
        I'm a little confused about the intended difference when it comes to
        language issues.

I figure that sending specific, technical implementation and language
design questions only to RRRS-Authors is appropriate since generally
most of us don't have the time to educate the 150 SCHEME list members
about things which will probably confuse or mislead them, and which they
probably don't care much about anyhow.  Messages to RRRS-Authors are
easier to compose since we can sassume more sophistication on the part
of the recipients.  Also, the smaller group can come to consensus on
complicated questions much faster and much less painfully than the
larger group.  I don't mean this to sound elitist, only pragmatic.

    (2) When a given lambda expression is evaluated more than once, is it
        required/allowed/disallowed that the procedure objects returned
        be EQ? to each other?  ... Does anyone object to adding similar
        language to the RRRS to clarify our intent?

This is a good idea; the wording in the CL manual is pretty good.
We definitely want to permit, but not require, things like
	(LET ((Z ...))
  	  (LET ((F (LAMBDA () (LAMBDA () Z))))
            (EQ? (F) (F))))
and
	(EQ? (LAMBDA (X) X) (LAMBDA (Y) Y))
and even
  	(LET ((F (LAMBDA (X) (LAMBDA () X))))
          (EQ? (F 'A) (F 'A)))
to return true.  The usual rule is that if there's any way to
distinguish two objects, EQ? of them must return false, but if there
ISN'T, EQ? is permitted to return true, and in certain special cases
(like that of symbols) is required to return true.  This applies to
closures just as it does to numbers.

Maybe a 2nd edition of the RRRS is in order, say, for next summer?  I'll
even volunteer to oversee its production, if no one else steps forward,
since the number of changes should be pretty small.