[Openmcl-devel] macroexpand-all

Tim Bradshaw tfb at tfeb.org
Wed Jun 25 00:58:41 PDT 2014


On 24 Jun 2014, at 21:46, Taoufik Dachraoui <dachraoui.taoufik at gmail.com> wrote:

> 3.1.2.1.2' .... "If the car of the compound form is not a symbol, then that car is either a lambda expression in which case the compound form is a lambda form or it is a macro form ..." ...
> 
> Does this contradict anything else in the spec?

Not really, I think. Its not self-consistent as it stands because in ((lambda ...) ...) the car of the form is both a lambda form and a macro form, but this can be easily resolved.  However restricting it to a macro form is silly: just let it be a form which will be compiled in the normal way, leading to a semantics which is essentially a Lisp 2 with a fallback Lisp 1 in the case that the car of the form is not a symbol.  I can imagine people not liking that but I'd be happy with it.  That clause would then read something like

"If the car of the compound form is not a symbol then it is a form which will be evaluated and should return a function ..."

(Note you no longer need the special case for ((lambda ...) ...) which is nice).

I think this is the semantics that Ron's hack (meant in a good way) implements.

The only thing that *can't* work is that you can return a macro function there, as that would make compilation impossible.

I think it would be easier if you used the conventional terms for read/macroexpand/compile/run time: there can be good reasons to use alternative terminology but those are when the existing terminology is inadequate, which it is not in this case.





More information about the Openmcl-devel mailing list