Issue: DOTTED-MACRO-FORMS (Version 2)

[masinter.pa@Xerox.COM]

Well, there is a large cost associated with adding another declaration that
has semantic import. 

Didn't we have some issue about whether

(EQ L (APPLY #'(LAMBDA (&REST X) X)  L))
and was

(APPLY #'(LAMBDA (&REST X) X)  '(A B . C))

an error?

although I forget its name offhand. Isn't this related? I.e., can't we
assume that argument lists don't end in dotted pairs?

I'd hope that they'd be resolved consistantly. My implementor's hat would
like to see APPLY have the ability to spread its arguments and make &REST
cons if it had to. Somewhat inconsistent with my original opinion on dotted
macros.

I guess I wasn't convinced by Neil's example, so I think I'm going to
support :DISALLOW.



!
Issue:        DOTTED-MACRO-FORMS
References:   forms (p54), lists and dotted lists (pp26-27),
	      DEFMACRO (p145), destructuring macro arguments (p146)
Category:     CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
			 1-Oct-88, Version 2 by Masinter

Problem Description:

  CLtL is not explicit about whether macro forms may be dotted lists.

  p54 says that only certain forms are "meaningful": self-evaluating
   forms, symbols, and "lists".

  pp26-27 defines "list" and "dotted list". It goes on to say
   ``Throughout this manual, unless otherwise specified, it is an
   error to pass a dotted list to a function that is specified
   to require a list as an argument.''

  p146 states that in DEFMACRO destructuring, ``the argument
   form that would match the parameter is treated as a
   (possibly dotted) list, to be used as an argument forms list
   for satisfying the parameters in the embedded lambda list.''
   It goes on to say that ". var" is treated like "&rest var"
   at any level of the defmacro lambda-list.

Proposal (DOTTED-MACRO-FORMS:DISALLOW):

 Specify that it is an error for a macro form to be a dotted list.

Rationale:
  
    Dotted lists are a possible symptom of program syntax error.
    Allowing implementations to check for this error may catch enough
    errors to justify the loss of program flexibility.

Test Case:

  #1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
      (MACW . 1) => ??

  #2: (DEFMACRO MACR (&REST R) `(- ,R))
      (MACR . 1) => ??

  #3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
      (MACX . 1)

    (MACW . 1) would be an error under this proposal.
    (MACR . 1) would be an error under this proposal.

Current Practice:

  A. Some implementations bind W to (MACW . 1) in #1 and #3
   		      and bind R to 1 in #1 and #2.

  B. Some implementations bind W to (MACW . 1) in #3
		      and signal a syntax error in #1 and #2.

  C. Some implementations signal a syntax error in #1, #2, and #3.
     Symbolics Genera is such an implementation.

Cost to Implementors:
  
As written, this proposal doesn't require implementations to check for
the error condition.
  
Cost to Users:
  
 Some users depend on this behavior in current implementations, although
such use is not widespread.
  
Benefits:

 People would know what to expect.

Aesthetics:

Mixed opinion; certainly it is better to specify whether they are allowed
 or an error than to be vague. Some feel that disallowing dotted macro
forms makes the language cleaner.

Discussion:

 Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
 
Allowing dotted macro forms may blur the data/code distinction too much, 
particularly for people who are new to Lisp.

Some people believe that there's no reason to unnecessarily restrict
&WHOLE and/or &REST since there is no computational overhead and since
the interpretation, if there is one at all, is pretty well agreed upon.