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: