Adam Warner <lists@...> writes:
> >> Each implementation's respective macroexpand-all function is unable to
> >> macroexpand MULTIPLE-VALUE-BIND. In each case I have also checked that
> >> MULTIPLE-VALUE-BIND is implemented as a macro:
> >> CMUCL:
> >> (walker:macroexpand-all '(multiple-value-bind (a b c) (fn)))
> >> => (multiple-value-bind (a b c) (fn))
> >> (macroexpand '(multiple-value-bind (a b c) (fn))) =>
> >> (multiple-value-call
> >> #'(lambda (&optional a b c &rest #:g1582) (declare (ignore #:g1582)))
> >> (fn))
> I was only trying to help the projects by reporting what appeared to be a
> To support multiple implementations I needed to fully macroexpand forms
> and then support a knowable, fixed, ANSI set of special operators. Since
> Sam explained that "implementations are free to define new special
> operators" and macroexpand-all/expand-form doesn't expand these it turns
> out that I can't rely on it to only return a form containing a portable
> set of special operators.
> This I need to write my own code walker. Which I can do.
1. I doubt that writing your own code walker will save you from
implementation-specific language extensions such as TRULY-THE,
COMPILER-LET or NAMED-LAMBDA.
2. M-V-BIND is a portable macro, which some implementations consider
to be a special form. The reason for it is that M-V-BIND is more
often used than M-V-CALL, so it is more important to optimize than
more general forms; and optimizing an explicit form is easier than
recognizing all possible patterns it may be translated to.
How is it hard to you to support one more special form with
standardized syntax and semantics? Of course, a key :EXPAND-KIND with
possible values :FULL and :COMFORTABLE could be added to SB-WALKER,
but will it be useful?
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer