[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Macros -> declarations
Date: Thu, 16 May 1985 22:45 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
We've kicked this idea around before in various forms, including the use
of some sort of syntactic marker on special bindings -- something like
turning FOO into $FOO if the variable is special, or treating the *FOO*
convention as being a declaration of specialness. Other lexical Lisps
have done this sort of thing with no obvious ill effects (and arguably
some good effects), but it seems to have been too radical a change to
have been seriously considered by most of the Common Lisp people when
the language was being designed. It would be even tougher now that the
langauge is starting to be used and assorted companies are rushing to
get implementations out.
Personally, I like the idea. I've felt for some time that we ought to
separate SPECIAL declarations from all the others, even if that means
that Common Lisp ends up looking a little different from Maclisp.
Referring specifically to your comments about a standard (enforced) naming
convention for specials...
* For the record, some programs like Macsyma use the printname of symbols to
record other kinds of information and would have to be radically restructured
to adapt to such a scheme. eg, in Macsyma any symbol with $ is accessable to
the Macsyma user; ie, the macsyma expression FOO+BAR parses to something involving
the Lisp symbols $FOO and $BAR. Since there need to be some special variables
accessible to users and others which are not, this kind of change would cause
all kinds of hassle.
Admittedly, such a convention is just poor excuses for a package system,
but its semantics is much different than the CL package system and it's not a
trivial syntactic change to convert things.
I suspect this isn't an isolated example. The Programmer's Apprentice has a
ton of code (by Dick Waters) which prefixes a digit to every symbol so you
can tell what module it belongs to. eg, its "database" code uses names like
8FOO and 8BAR while the display module uses 7FOO and 7BAR. I suppose a
-very- careful Query Replace of "DISPLAY:" for "7" would almost "fix" things,
but it'd be fairly tricky.
* In general, I would want to avoid attaching language semantics to the print
name of a symbol. It's bad enough that all symbols with & as their first
char or that are interned on the keyword package are reserved. For example,
if specials had different print names than other symbols, you'd need to
add a :SPECIAL-P keyword to GENTEMP which said whether to do hair to make
sure the symbol had a print name suitable to be a special variable. Various
other applications that concatentated symbols to make new symbols in macros
would have to use care not to produce symbols like OLD-*FOO* (preferring,
I suppose *OLD-*FOO*) or OLD-$FOO (preferring $OLD-$FOO). There used to be
something nice about the sanctity of a symbol ... I feel as if we're starting
to walk all over that. I hope we will move -away- from having reserved symbols.
eg, eventually (might take a while before we can swing it) flushing &keywords
in the bvl for :keywords, and making :keywords not be SYMBOLP.
... But we should only make this move so late in the game if just about
everyone else feels likewise.
Wouldn't want you to think they did.