This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC | Extending Common Lisp support


Thanks for the information everyone. I must say I'm loosing sight of
the goal with these suggestions. I had not anticipated problems
DEFMACRO (I assumed it was fully functional when I saw it in the docs,
but I must have misread something, apologies about this). LOOP seems
like it's going to want a full-featured DEFMACRO (destructuring at
least). It seems unwise to try and implement something like LOOP when
DEFMACRO isn't complete. I'd like to implement LOOP in CL, rather than
stub calls to Java code.

I've incorporated Jamison's suggestion for getNamedLispType to uses
strings rather than classes, I have the following behaviour from both
Scheme and CL which seems undesirable:

#|kawa:2|# |clisp:t|
ClassType java.lang.Object

The old behaviour was to output Type boolean. For that to work, there
needs to be a default boolean type in LispLanguage, which to pick? For
reference, Scheme's boolean type is initialised like this in Scheme:

booleanType = new LangPrimType(Type.booleanType, Scheme.getInstance());

Currently I am still trying to refactor this type processing, but I'm
unearthing some inconsistencies with old behaviour (such as that
described above)

Thanks,

--
Charles Turner


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]