Re: GSOC | Extending Common Lisp support

[Jamison Hope <jrh at theptrgroup dot com>]

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