Symbol Macrolet

[Scott.Fahlman@B.GP.CS.CMU.EDU]

I haven't seen the full Symbol-Macrolet proposal, so I can't comment on the
details, but I think that we have needed something like this for a long
time.  Lisp is, among other things, a powerful language in which to write
other languages, and the ability to extend its syntax via macros is an
important part of that power.  Unfortunately, this extensible syntax has
only been available at the form level and not at the symbol level.  When
people have felt the need to have symbols that turn into something more
complex, they have had to rely on code-walkers that are external to the
language -- an error prone situation at best.  Symbol macros would fix
that, and if they are lexically scoped they would not be too treacherous in
the hands of a reasonably careful programmer -- at least you could see
locally what symbols you want to handle with care.

It has been suggested that this mechanism puts too much power into the
hands of the Lisp user -- enough power to confuse readers of the code,
whether they be programs or humans.  I feel that Lisp is a language that
has always chosen to give the most powerful tools to the programmer, who
can use that power either for good or evil.  Given the ability in Common
Lisp to modify code on the fly, to pass around function objects containing
shared state, to create macros that perform arbitrary transformations on
chunks of program, and to alter reader syntax beyond all recognition, the
Lisp programmer who chooses to do so already has the power to create
totally impenetrable code.  We don't want to add constructs to the language
that are gratuitously dangerous, but neither do we want to keep useful
tools out of the hands of good programmers just because bad programmers
might get into trouble.

If you want a language that tries to lock up all the sharp objects and
fire-making implements, use Pascal or Ada: the Nerf languages, harmless fun
for children of all ages, and they won't mar the furniiture.

-- Scott