#

## Issue MACRO-AS-FUNCTION Writeup

    Issue:        MACRO-AS-FUNCTION
    References:   Chapter 1, Section 1.5, Working draft of standard
    Category:     Clarification
    Edit history: 8-JAN-89, Version 1 by Masinter
    	      6-FEB-89, Version 2 by Chapman

    Problem:

    May operators defined in the standard as "macros" and
    "special forms" be implemented as functions instead? PROG1 is the main
    example, but there might be others.

    Proposal: MACRO-AS-FUNCTION:YES

    Operators that are defined in CL as "macros" may be defined as functions
    instead if the semantics can be preserved.

    This is rare, perhaps only
    restricted to

    (defun prog1 (value &rest ignore) value)
    (defun prog2 (value1 value2 &rest ignore) value2)

    Operators defined as "special forms" may also be defined as functions.

    Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO

    The standard will remain silent on the issue of whether or not is
    is legal for an implementation to implemention "macros" and
    "special forms" as functions.

    Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW

    A conforming implementation does not define "macros" and "special forms"
    as functions.

    Rationale:

    There isn't a good reason to disallow "macro" and "special form" function
    definitions. It doesn't interfere with portability.

    Current Practice:

    One implementation defines PROG1 as a function.

    Adoption Cost:

    None for :YES; some for :DISALLOW.

    Benefits:

    Increased implementation flexibility.

    Conversion Cost:

    None.

    Aesthetics:

    None.

    Discussion:

Copyright 1996-2005, LispWorks Ltd. All rights reserved.