[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Sunday, 23 March 1986 18:10-EST
From: Jonathan A Rees <JAR at MC.LCS.MIT.EDU>
I'd like to change the meaning of (DEFINE (form var ...) body ...) so
that it's defined in terms of LAMBDA instead of NAMED-LAMBDA.
I don't like this, and would prefer that
(DEFINE (FOO BAR BAZ) ...)
(LETREC ((FOO (LAMBDA (BAR BAZ) ...)))
this additional complication mostly to eliminate the need for either
REC or NAMED-LAMBDA.
My reasoning is that this semantics solves a classical problem: namely
that if FOO is self referential, then subsequent redefinition of the
variable FOO will cause the originally defined procedure to change its
behavior. In particular, suppose that the procedure value of FOO is
bound to the variable BAR, and then FOO is redefined to some
completely different value, say (just to be extreme) the number 3.
I claim (and I believe that there will be support for this claim) that
the INTENT of the author of such a self referential procedure was that
the name FOO refer to the procedure itself, not the binding of the
variable FOO. This is because the binding is normally assumed to be
fixed; interactive definitions are something that the language has
because we recognize the need for debugging and evolution of our
programs. And the more naive the user, the more confusing it will be
if the procedure FOO depends on the value of the variable FOO, rather
than meaning "self reference".
Now, the reason why everyone wants the meaning of DEFINE to avoid the
use of LETREC (or its special case NAMED-LAMBDA) is obvious: it is
simpler to explain to people who are learning the language. However,
I think that this is detrimental in the long run, because sooner or
later many of those students who learned the simpler DEFINE semantics
will get screwed by the fact that their intuition didn't match the
semantics. I feel that teaching this subtle point would not take much
effort. Furthermore it would illustrate an important concept in
language design: that semantics should interact with our intuitive and
esthetic concepts of how a language should behave.