[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Which constants must be quoted?

    Date: 10 Feb 86 10:25:17 PST (Mon)
    From: willc%tekchips%tektronix.csnet at CSNET-RELAY.ARPA

    As for vectors, I think we decided not to decide at Brandeis, and so the
    draft I sent off to MIT did not mention characters or vectors on page
    12.  They were added at MIT as part of the final editing performed (I
    assume) by Gerry Sussman and Hal Abelson..

    I agree with the change, but some might question the decision on vectors.
    There seem to be approximately two principled answers to the question of
    which values must be quoted (answer 1: everything; answer 2: only symbols
    and nonempty lists).  Any other answer will include arbitrary distinctions,
    about which no definitive argument can be made.

I think that I and other people associated with T are the holdouts here.
In a language based on evaluation instead of normalization, answer 1 is
the "right thing," but unfortunately, if we're to be Lisp-like, we
should permit omitting the ' in the case of numbers and strings.  2 is
unacceptable because it makes the class of permissible programs larger
than necessary, and therefore reduces opportunities for error checking.
For example, suppose there's a bug in a macro, and it returns a closure
instead of a lambda-exparession.  Or suppose that due to an FTP or
editor bug, or even a typo, a stray # was inserted into a source file
just before a parenthesis.  These situations would be very difficult to
debug if closures and vectors were legitimate expressions.

So I think that an intermediate position between 2 and 3 *can* be
justified by the principle of Occam's razor, and we should disallow
self-evaluation of vectors, procedures, and other "random" objects
because it's unnecessary.  That is, the class of legitimate programs
should be as small as is reasonable.  Programming language tradition has
numbers and strings self-evaluating; everything else is dubious.  In the
case of composite objects like vectors and procedures, we should not
lock out the future possibility that a meaning other than
self-evaluation might be assigned in the future.  For example, I don't
see any a priori reason why vectors should be treated differently from
lists; seems to me that #(CAR '(A B)) has as much right as (CAR '(A B))
to evaluate to A.  Similarly, perhaps a procedure would want to be
invoked (or "sent a message"?) to produce a value.

I don't care much about booleans and characters; they could go either
way as far as I'm concerned.  I guess I only advise updating the manual
to state clearly that characters self-evaluate.

It is true that distinctions become arbitrary here, but in each case we
can apply judgement the same way that we applied judgement in the
inclusion of any language feature.  I think it's hoping for too much to
look for definitive arguments; much of the language would suffer
severely under such scrutiny.

I disagree with Chris's statement that it is "Lisp tradition" for random
objects to self-evaluate.  I have seen messages like #73556 UNEVALUABLE
DATUM in Maclisp and other dialects more times than I can remember, and
I have always been happy to see them, because they have always put me on
the road to eliminating yet one more bug.