RE: Issue: SYMBOL-MACROLET-UTILITY

[piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)]

> 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
>   discussion here>.


I'm not completely happy with the problem description as it stands, either.  I
see the issue as essentially a choice between (a) fixing the semantics of
SYMBOL-MACROLET to match the semantics of MACROLET, or (b) doing without
SYMBOL-MACROLET.  I had thought I could separate these into two issues
(namely, keep-vs.-flush first, and fix the semantics only if flush fails), but
now I think I should combine them into one issue after all.  This will be
forthcoming.
 
>    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.
> 
>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.

The namespace argument is a valid one; I'll put that in "Cost to Users".  This
is honestly the first pro-SYMBOL-MACROLET argument I've heard that has more
substance than "But it'd be neat to have SYMBOL-MACROLET."

Characterizing the namespace collision problem as "huge," based on the example
you give, assumes that (a) people have some proclivity toward using names that
conflict with function names like "car" and "cdr", (b) they'd use the same
name for both the macro and the slot (cf. defstruct and the :conc-name prefix
mechanism), and (c) someone writing

		(macrolet ((car () ...)) ...)

wouldn't see the name collision.  I might believe the first assumption
(especially for names like "list"), I'm more dubious of the second, and I
really have a hard time swallowing the third assumption.  Even in a Lisp-2,
programmers are used to avoiding name conflicts.

I tend to believe that changing WITH-SLOTS and WITH-ACCESSORS could eliminate
CLOS' need for SYMBOL-MACROLET altogether, if they just generated MACROLET
macros with prefixes.

 
>     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.
 
I guess I was getting ahead of myself here.  I'd been taking it as an almost
foregone conclusion that, if SYMBOL-MACROLET is kept in the language, it would
be promoted to a special form, in which case the PCL implementation doesn't
really help anybody.  Another reason to combine this with the
fix-the-semantics issue.

/JEP