Macros -> declarations

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    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.