semantics of DEFINE

[Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)]

In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT
(Mark A. Sheldon) writes:
>Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
>Restricting DEFINEs to beginnings of blocks allows us to think of a block
>of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
>that don't implement these blocks as a LETREC).  If Scheme is a statically
>scoped language, then this sort of DEFINE is anathema.  If Scheme is to
>support dynamic scoping, then I think FLUID-LET is cleaner because I don't
>have to think about environment mutation.

A while ago I posted the suggestion that non-top-level DEFINEs do the same
thing as top-level DEFINEs, ie, side effect the top level.  This allows
top-level definitions to scope over lexically bound variables, which cannot be
done in any other way (as of now a single procedure can scope over variables,
but such variables cannot be shared by procedures); having non-top-level
DEFINEs side effect the local lexical environment is the same as LETREC
(perhaps nested) and thus doesn't add any functionality.  This interpretation
is the one adopted by the current version of T (although it's not an explicit
decision on the part of the T designers) and I believe is the interpretation
used by most LISP dialects.  The ability to have global procedures scope over
variables reduces the number of unneeded global variables, allows hiding of
internal representations, and (almost definitely) adds alot to the efficiency
of accessing these variables.

Most of the responses that I got said either like "well, Abelson and Sussman
used the 'local' interpretation, so we really should stick to it" or "well,
local non-top-level DEFINEs add fewer parentheses than nesting LETRECs."  Does
anyone have other (theoretical or functional) reasons for this decision??


Bruce Krulwich