[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: SYMBOL-MACROLET-UTILITY
- From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
- Date: 22 Jun 88 17:38
I'm getting to ready to submit this as a cleanup proposal; I thought I'd run
it by here first. My intent in submitting the proposal for cleanup is to open
the discussion of whether SYMBOL-MACROLET is really a desirable language
feature. If it is resolved that SYMBOL-MACROLET is worth keeping, I have a
follow-up proposal to at least make it a special form.
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Edit history: 21-Jun-88, Version 1 by Piazza
Anything expressible with SYMBOL-MACROLET could also be written with
regular MACROLET, except that the macro symbol could not stand alone as an
expression; it would have to be enclosed in parentheses. The cost
associated with implementing and maintaining the SYMBOL-MACROLET feature
exceeds this incremental utility.
Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.
Flushing SYMBOL-MACROLET eliminates the cost of implementing and
maintaining this feature, while MACROLET still provides most of
SYMBOL-MACROLET's expressive power.
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R.
Cost to Implementors:
Presumably few implementors have implemented SYMBOL-MACROLET, excepting
the implementation provided by PCL. If it is flushed from the language,
no one will incur any implementation cost.
Cost to Users:
Users will lose the expressive ability provided by SYMBOL-MACROLET,
WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.
Cost of Non-Adoption:
Implementors must implement significant new functionality, adding to
system size and language complexity. (A separate proposal,
SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
specified semantics of SYMBOL-MACROLET.)
SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
a Common Lisp implementation. It also simplifies the language by
eliminating the concept of a "symbol macro."
There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
as a construct in the language. Some feel it hairs up the language while
offering only trivial benefit beyond what is already provided through
normal macros. Others herald it as a important new language feature.
As it was adopted by X3J13 as part of CLOS, there has been no formal
discussion on the pros and cons SYMBOL-MACROLET on its own.