SYMBOL-MACROLET-UTILITY

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

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.

/JEP
===============================================================================
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.

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.

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

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.

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

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.