Re: GSOC | Extending Common Lisp support

[Charles Turner <chturne at gmail dot com>]

On 25 June 2012 21:15, Jamison Hope <jrh@theptrgroup.com> wrote:
>> SETQ doesn't seem to be working from with LET:
>>
>> (let ((res nil))
>> Â(setq res 5)
>> Âres) ;=> nil
>
>
> Hmm, are you seeing a warning in there? [Not sure if our local versions have
> diverged.]
>
> #|kawa:1|# (let ((res nil)) (setq res 5) res)
> /dev/stdin:1:18: warning - no declaration seen for res
> ()
>
> That tells me that inside of SETQ it's not finding the correct res. Sure
> enough,
> it looked for one at top level, didn't find one, and made a new binding
> there:
>
> #|kawa:2|# res
> 5
>
> Looks like setq#rewriteForm needs to have a tr.rewrite(name) in there to get
> a ReferenceExp the way set_b#rewriteForm does.

I am seeing the warning, just being terse! Ah, I see now. Hopefully
Helmut's suggestion will work for me when I get round to it tomorrow.

>> However, SET! does work, which I know I probably shouldn't be using,
>> but I wanted to try getting further on DEFPACKAGE after spending a
>> while on this bug.
> For the moment, if it works then go for it. We can fix it later.

Mm, I've followed this policy on a number of issues, for better or worse.

>> PRIMITIVE-THROW isn't working in CL:
>>
>> (primitive-throw (<java.io.IOException>:new
>> ((format #f "cannot delete ~a" file):toString)))
>> /dev/stdin:2:18: warning - no field or setter 'new' in class
> Instead of :new (which relies on colons working as they do in Scheme),
> try MAKE. Something like:
>
> (primitive-throw (make <java.io.IOException> (invoke (format #f "cannot
> delete ~a" file) 'toString)))

As God is my witness, if I forget I changed the colon semantics once
more, I will destroy my computer. I wasted another 15 minutes earlier
wondering why I couldn't access a field using obj:field... (I know
about FIELD, I was just being dumb)

> Either way we would also need to change that part of LambdaExp to do the
> appropriate thing.

Thanks again Jamison, I'll look into this at some point! Thanks both
of you for the suggestions of getting around the supplied-p problem, I
actually solved my problem by postponing the implementation of this
particular feature :-)

Is the following kosher? I know this is more of a reader problem, and
I've been hacking around it in all sorts of places, but it was causing
me problems, this patch stopped those problems for me and the test
suite still completes (in Symbols.java):

   public static Object getPrintName(Object sym)
   {
     return sym == Lisp2.FALSE ? "nil"
-      : Lisp2.getString(((Symbol) sym).getName());
+      : Lisp2.getString(((Symbol) sym).getName().toUpperCase());

that seems to do The Right Thing, but IIUC, it will be unnecessary
when the reader is fixed, right? The reader will populate the name
field of Symbol with an upper case string in the case of CL. Just
checking.

I'm attaching my primitives file (nothing much interesting has
happened, more of a sanity check), I've almost got the plumbing ready
to finish DEFPACKAGE off, seems like just UPDATE-PACKAGE to go (ha).
I've been using SBCL as a reference implementation, but I haven't had
chance to meet with my lawyer yet, so I'm not sure what the procedure
is in terms of licensing. I know Per used their pretty printer, so I
assume he did the legal dance (if any) in one of the licence files.

Charlie.

Attachment: primitives.txt
Description: Text document