[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SYMBOL-MACROLET-UTILITY
- To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
- Subject: Re: Issue: SYMBOL-MACROLET-UTILITY
- From: Gregor.pa@Xerox.COM
- Date: Wed, 29 Jun 88 13:44 PDT
- Cc: firstname.lastname@example.org
- Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
- In-reply-to: <8806281758.AA10391@decwrl.dec.com>
- Line-fold: no
Date: Tue, 28 Jun 88 10:58:00 PDT
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
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.
This isn't a problem description, it is a statement of opinion. A
problem description would say something like:
The symbol-macrolet utitily introduced with CLOS has some semantic
problems. <discussion of these problems here>. These problems may
cause problems with some existing code <extension of previous
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.
The explanation of the hack of using the symbol as what looks like a
no arguments function should be presented here. There needs to be a
discussion of the fact that this would work much better in a Lisp-1
than a Lisp-2.
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
Another cost is that they won't be able to overload names to mean both
a real function and one of these hack macros. For example:
(defclass foo () (car cdr))
(defun describe-foo (foo)
(macrolet ((car () (slot-value foo 'car))
(cdr () (slot-value foo 'cdr)))
Can't use normal car and cdr in here
Of course this is something that Scheme programmers are used to dealing
with. But Common Lisp programmers are not. The potential for this
seriously aggravating the existing problem with macro expansions
capturing the wrong lexical context is huge.
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.)
I am not sure I buy this. For one, there is already an implementation
of it in PCL. For another, any exiting compiler must already have the
right stuff in it to do this.
If you insist on doing an entirely custom CLOS, the work required to do
this part of it is very small compared to the work required to do the
rest of it.
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.
That discussion should appear in this part of the proposal.