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:
> 126.96.36.199.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