[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Re: Issue: DOTTED-MACRO-FORMS (Version 2)]



     Well, there is a large cost associated with adding another declaration 
     that has semantic import. 
I understand why adding declarations WITHOUT semantic import is always
easy on implementors.  But I don't understand how adding declarations
WITH semantic import is necessarily costly for them.  In particular, since
people whom I assume to be knowledgeable stated that it would be trivial
form implementations to either accept or reject dotted macro forms, I don't
see why a user declaration to control this on a per macro basis would
be very costly for them.  In particular, why would it be any more costly
than any other clarification of the dotted macro issue?  (Except for specifying
that "it is an error" rather than "an error is signalled", which
would let all the implementors continue to be inconsistent, but has no
other redeeming characteristics in this situation.)

   Didn't we have some issue about whether
   (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?

Since it is not legal to APPLY macros, and since macro lambda lists already
have a syntax that allows things NOT allowed in lambda lists of
APPLYable lambda, the resolution of one issue doesn't NECESSARILY tell
us how to resolve the other.

However, I would very definitely see a virtue in having the language
defined so that it was guaranteed that whenever I saw an &REST variable
it was guaranteed to be bound to a non-dotted list (or NIL).

I wouldn't be terribly bothered by totally outlawing dotted argument lists,
if it were done uniformly (although I would prefer that they be allowed
in cases where the programmer explicitly indicated a willingness to
accept them.)  But, unless I misunderstood the :DISALLOW proposal,
only top-level dotted lists are disallowed.  One could still write

		     (MY-MACRO (x . :all) (foo x) (fum x))

where the dotted argument is not at the top level, and
receive the parameters with either
   (var-and-control &body forms)
or with
   ((var . control) &body forms)
or even 
   ((var &rest control) &body forms)
which binds the &rest to (x . :all).

Why are top-level dotted argument lists so much more objectionable than
embedded ones, so that it makes you want to have a different semantics for
the embedded lambda lists in the macro syntax?

Neil