This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
Hi Charles,
On May 19, 2012, at 8:42 PM, Charles Turner wrote:
On 19 May 2012 23:35, Jamison Hope <jrh@theptrgroup.com> wrote:
Can you send us a diff against trunk? I know you're busy with
school work,
but I'm eager to see what you've been up to. I'm not expecting it
to be
completely polished and ready to check in, so if it's still got rough
edges that's OK.
See attached. Hopefully you'll be able to see if I'm on the right
track.
Looks good for the most part. A few questions/comments:
1. I presume that this change in PropertyLocation.java
- if (symbol instanceof Symbol)
+ if (symbol instanceof Symbol && lloc != null)
is intended to avoid a possible NullPointerException? But after that
if block there's an unguarded "lloc.set(plist);" anyway, so you'll
still get the NPE, just at a different line number.
2. In moving the bulk of checkDefaultBinding() from
SchemeCompilation.java
to Translator.java, the XmlNamespace/unitNamespace checks have been
effectively reordered to be after the "ends with '?'" check. Does
that
have any functional repercussions? (I suspect not, but haven't
tested either.)
3. Also in the checkDefaultBinding() relocation, Translator.java now
has:
int len = name.length();
char ch0 = name.charAt(0);
where the SchemeCompilation version used to have an "if (length ==
0)"
check in between. Could that be a problem? Is name ever the empty
string?
4. Scheme.getNamedType() directly calls
LispLanguage.getLispTypeMap().get(),
but it looks like it should be calling
LispLanguage.getNamedLispType()
instead, as that's where the name.startsWith("clisp:") stuff is now.
Also, evaluating |clisp:boolean| in Scheme doesn't work anymore,
even if
LispLanguage.getLispTypeMap().get is replaced with
LispLanguage.getNamedLispType. It looks like this is because
LispLanguage.getNamedLispType("boolean") returns null.
Re |clisp:boolean|, I got it to work again by adding
types.put ("boolean", Type.booleanType);
to the getLispTypeMap() initialization, so that then
Class clas = getNamedLispType(name.substring(colon
+1)).getReflectClass();
succeeds and passes Boolean.TYPE to CommonLisp's getTypeFor(Class),
which then
returns CommonLisp's booleanType.
But that seems too hackish. Also, with that in place, I wind up in
this strange
situation (I added a toString() method to LangPrimType in order to
tell it apart
from a raw PrimType -- public String toString() {return
super.toString() + " - " + language;}):
$ kawa --lisp
#|kawa:1|# boolean
Type boolean
#|kawa:2|# |clisp:boolean|
Type boolean - gnu.commonlisp.lang.CommonLisp@35175422
That's because CommonLisp doesn't override Lisp2's getNamedType(),
which just
defers to LispLanguage.getNamedLispType(). The only way to get the
correct Type
is to (somehow) first get the corresponding Class and pass it to
getTypeFor(Class).
In particular, note that CommonLisp.getTypeFor(String) will not do the
right thing.
I think this is related to the "CL not is not not" bug I came across a
few weeks ago.
This is turning out to be quite the rabbit hole. :-/
It looks like you're at least far enough along that class literals work,
and even if you still have to call it |clisp:boolean| I think you should
be able to finish translating PrimOps.scm now (if you incorporate my
above hack).
Clearly there's a sizable mess here with getTypeFor(String) vs
getTypeFor(Class)
vs getNamedType(String) vs string2Type(String), and that's tangential
to your
actual proposed summer project.
Per, what if you and I (yes, I am aware that likely simplifies to "I")
take over
that part of it so that Charlie can focus on DECLARE, sequences, and
LOOP?
(Will 1.12 be coming soon so we can check some of this stuff in?)
-Jamie
--
Jamison Hope
The PTR Group
www.theptrgroup.com