Re: Symbol-Macrolet

[cperdue@Sun.COM (Cris Perdue)]

> Issues surrounding Symbol-Macrolet
> 
> - Incompatible Language Change
> 
Granted that symbol-macrolet affects the meaning of symbols
in expressions generally, and code walkers in particular.  Code
walkers will indeed have to be modified to handle symbol macros.

The specter of misuse of of symbol-macros is a red herring.  Lisp
already has plenty of power that can be misused to make programs
confusing or worse.  The SETF concept and even the concept of
macros provide this level of power.

The concern about Common Lisp not being a very safe place to write
programs boils down to the fact that macros that analyze their bodies
as Lisp code will need to be modified to expand any possible symbol-macros.

> - Symbol-Macrolet should at least be a special form.
> 
This does seem necessary.

> - It shouldn't be part of CLOS
>
Yes, I thought it was going to be proposed as an independent change
to Common Lisp which could then be used to support with-slots.

> - Who needs it, anyway?
>
The inventors of Flavors, of CLOS, and of CommonObjects all considered
the syntactic convenience important to their users.  I was privy to
the discussions and thinking that went into a predecessor of CommonObjects
and I know that this syntactic convenience was considered important.
SmallTalk also makes instance variables and local variables syntactically
the same.

To me, symbol-macros are an exciting development.  In my experience
software writers almost always avoid making interfaces with a function
and a "setf" for it unless the function takes at least one argument,
even though this supports extra bookkeeping that may be desirable, where
just using a variable does not.  With symbol-macros it will be possible
to use the variable notation that people like and get the abstraction
that we get from functional interfaces.

There are other things that behave like variables, but
aren't quite, that would be supported by symbol-macros.  In other
words, I see valid and important enhancements to Common Lisp that
will be opened up by symbol-macros, and I'm glad that they are
being proposed rather than just a special case for CLOS.
Even a special case for CLOS would be a change to the language,
and symbol-macros provide generality.