Re: Issue: SYMBOL-MACROLET-UTILITY

[Gregor.pa@Xerox.COM]

    Date: Tue, 28 Jun 88 10:58:00 PDT
    From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

    Status:		DRAFT
    Issue:		SYMBOL-MACROLET-UTILITY
    References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
    Category:	DELETION
    Edit history:	21-Jun-88, Version 1 by Piazza

    Problem Description:

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

    Proposal (SYMBOL-MACROLET:FLUSH):

	Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.

    Rationale:

	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.

    ------------------------------------------------------------------------------

    Current Practice:

	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.

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.

    Benefits:

	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."

    Aesthetics:

	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.

    Discussion:

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