Re: [Kawa-commonlisp-dev] [GSoC] Status

[Helmut Eller]

On Sat, Aug 11 2012, Charles Turner wrote:

> Thanks Jamison & Helmut for the explanation.
>
> On 11 August 2012 08:06, Helmut Eller <address@hidden> wrote:
>> A macro defined with syntax-case returns an identifier (that's not a
>> symbol but some more complicated thing) that carries additional
>> information, in particular the module it belongs to.
>
> Would arranging for DEFMACRO to return an identifier would violate
> ANSI?

Yes that would not violate the standard rules, since there are no
identifiers in ANSI CL and the expression 'FOO means a symbol not some
identifier.

> Or whether it would cause a lot of problems in general use. 

User defined macros can potentially call MACROEXPAND and look at the
return value to see if it contains a particular symbol.  That would
involve some use of EQ and that would not work with identifiers.

> I'm not sure how to approach such a change, need to read through the
> source more thoroughly. I think we need such a change though, as IMO,
> DEFMACRO is quite flawed here.
>
> I'll put this on my high priority list, but for the time being, I'm
> using the (require class::|defmacro or primitives|) trick to continue
> my testing. DESTRUCTURING-BIND passed all the test cases from the
> ANSI-TEST project, now I'm working through some more package tests.
>
> Thanks again for the help guys!

I think there is a circular dependency in the build procedure:
CommonLisp.java says that DEFMACRO can be found in primitives.lisp
but to compile primitives.lisp we need to load CommonLisp.java first
which wants to load primitives.lisp first ...

How is this supposed to work?  Is it even necessary to enumerate so many
names from primitives.lisp in CommonLisp.java when we are going to load
both files anyway?

Helmut