survey results (long message)

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

Here's a summary of the 16 completed surveys I received:

1. (EQ? (LAMBDA (X) X) (LAMBDA (Y) Y))

14 - I, 2 - F
Winner: I

This question, which I think is what the recent Bartley/JINX debate has
been about, was the only one on which there seemed to be consensus.
Everyone except Sussman and Halstead said that the result should be
implementation-dependent but not an error.  (Maybe JINX wants to change
his vote now?)  The dissenters definitely wanted the answer to be false.
I interpret the dissenting view as follows: evaluation of a
LAMBDA-expression MUST be a side-effect; a denotational semantics MUST
have locations associated with procedures; we must change existing
implementations (like T, and maybe TI's compilers); we must change the
RRRS, which is mute on this point; and Scheme must differ from Common
Lisp here.

My editorial opinion: Scheme should be compatible with the published
RRRS, with Common Lisp, with the majority, and with its current
implementations.  People who teach from S&I might want to note that some
scheme and CL implementations perform "coalescing" optimizations.

2. (EQV? (LAMBDA (X) X) (LAMBDA (Y) Y))

8 - I, 7 - E, 1 - F.
Winner: I

Half the respondents want EQV? to have the same implementation-dependent
behavior as EQ?.  The other half want EQV? to be defined in an
implementation-independent way.

Given the lack of consensus for change, I would again suggest the
conservative stance of leaving things as they are, compatible with the
RRRS and with Common Lisp's EQL.  I would be happy, however, if someone
continued this crusade and managed to convince all those people who want
an ugly EQV? that they're wrong.

3. (LET ((P (LAMBDA (X) X))) (EQ? P P))

9 - I, 6 - T, 1 - U.
Winner: T

Half want particular evaluations of lambda-expressions to "have
identity," thus again requiring a more complicated semantics involving
locations, and forbidding indiscriminate beta-conversion.  The other
half want simpler semantics, and the conceptual improvements and
implementation freedom which result.  (Please pardon my biased
interpretation, it's supposed to be mildly humorous.)

Again, there's no consensus, so I would recommend staying with the RRRS
and Common Lisp status quo, even though it's a "minority" position
(among those who turned in surveys) and in opposition to mine.

4. (LET ((P (LAMBDA (X) X))) (EQV? P P))

5 - T, 7 - E, 3 - I, 1 - U.
Winner: T

This was asking, among other things, whether the semantics of Scheme
needed to associate locations with procedures, even if EQ? were excised.
To be consistent with everything else, especially question number 2, I'd
say again we'd have to stick with the status quo.

5. (LET ((N <number>)) (EQ? N N))

5 - T, 9 - I, 1 - E, 1 - U.
Winner: I

Hard to interpret these results.  One issue that hasn't been raised is
that Common Lisp and RRRS disagree on this question; RRRS says that the
answer should be T, and Common Lisp says I (implementation-dependent -
numbers don't "have identity", can be "copied freely").  I think that
Sussman says that he and S&I don't care about numbers having identity,
and wonders why anyone would really care.  This topic might need more
discussion; e.g. one could use my argument (previously advanced to an
opposite end) that procedures and numbers shouldn't be treated
differently, with the conclusion this time that since procedures "have
identity", so should numbers.

Given that Scheme's EQ? is otherwise so close to Common Lisp's EQ, and
that a majority want to change scheme to be compatible with CL, it would
be a shame for them to disagree here, so I would be inclined to change
the report.  E.g. the way it is, it will be quite difficult to embed
scheme implementations in common lisp, and vice versa.  Note that this
change in the language definition would not require anyone's
implementation to change, although it might require some people's
programs to change (speak up if this is the case!).

6. (EQ? #\X #\X)

7 - I, 2 - T, 7 - X
Winner: I

I saw this question as asking more or less whether characters should be
"interned".  I think the consensus is that they don't need to be.  That
would be consistent with the RRRS and with Common Lisp.

[One respondent originally answered E on the grounds that characters
shouldn't be expressions, so this would be a syntax error; but I think
the consensus on that question is that characters SHOULD self-evaluate.]

----------

I guess I mounted this failed little crusade for pure location-less
procedures in an attempt to make Scheme have cleaner, more abstract
semantics, with the implication that this would have many practical
benefits.  I do believe that having a way to denote pure objects
(behaviors) would have far-reaching consequences.  But maybe Scheme is
an inapprioriate vehicle for this kind of progress; the "ideal
programming language" would probably differ from Scheme in many other
ways as well.

My advice to the Yale and TI efforts, which seem to agree with me on the
need for location-less procedures, is to implement both kinds of
procedures, and support two different dialects (or two different LAMBDA
special forms).  I know that the "native" T dialect already has to be
incompatible with Scheme in various ways (its DEFINE and WRITE and a few
other things differ incompatibly), and that semantically, at least,
impure procedures can be simulated in T by pure ones, so this is
probably not such a big deal - maybe involving a flag in the compiler's
LAMBDA-nodes, or maybe something more general.  I hope other people who
want to work on issues like this one which involve incompatibility with
Scheme will come up with similar solutions, implementing both crufty,
backwards Scheme AND the wonderful language of their choice, and not
give up on either line of work.

I'll try to come up with an objective, concise summary of this EQ?
debate to include in the next edition of the report.

Jonathan