GSOC | Extending Common Lisp support

[Jamison Hope]

On Jun 7, 2012, at 9:55 AM, Charles Turner wrote:

> Excellent! FLET is now working.

Hurray!

> I cleaned up my working set diff which
> includes all my work so far, just so if someone wants to have the same
> source code as myself, this patch should apply cleanly against trunk.
> I'm made no progress on the syntax-case bug, on the plus side, I have
> learned more about macros and how they're implemented.

Just figuring out how to *use* syntax-case correctly can be a real
challenge; implementing it bug-free can only be trickier (unless
your name ends with -ybvig I guess).

Anyway, I don't expect syntax-case to get much use from Common Lisp
(though I see no reason why that should be prohibited), so let's not
spend too much time on that right now.

> It seems like a good idea to try and get packages working (I didn't
> know much about them at the time I was writing my proposal, they
> weren't covered in the CL book I read in preparation), all of the CL
> libraries should be exposed through packages IMO.

Yeah, they're supposed to be exposed in a package called COMMON-LISP
(which has an alias called CL). To make things even more exciting,
"These external symbols are present in the COMMON-LISP package but
their home package need not be the COMMON-LISP package."
http://www.lispworks.com/documentation/lw51/CLHS/Body/11_aba.htm

At startup, we should be in the COMMON-LISP-USER package.
http://www.lispworks.com/documentation/lw51/CLHS/Body/11_abb.htm

Note the special (i.e. dynamic variable) *PACKAGE*:
http://www.lispworks.com/documentation/lw50/CLHS/Body/v_pkg.htm
which needs to be consulted when looking up symbols. I'm not entirely
sure how that should change the existing Environment searching.

Chapter 21 of Practical Common Lisp might help:
http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html

> Furthermore,
> DEFMACRO seems higher priority than LOOP, so it makes sense to me to
> get these things working before embarking on that. Again, a lack of
> preparation whilst writing my proposal, I hadn't realised DEFMACRO had
> these shortcomings.

C'est la vie.

> On 6 June 2012 20:56, Per Bothner <per@bothner.com> wrote:
>> I think the problem is where LambdaExp#compile calls  
>> emitLoadModuleMethod.
>> I don't think the branch at line 780 should be taken, or if it  
>> should be,
>> we should not rebind the outer procedure (see the comment in
>> ProcInitializer#emitLoadModuleMethod line 35).
>
> Did you look here from experience with the code, or was it debugger
> exploration? If so, what's you're standard entry point for bugs like
> this? I tend to work from the syntax transformers, but I wonder if
> there's a better place to start from.

Per probably Just Knew, but I looked at the output of --debug-print- 
final-expr,
saw that most of the relevant stuff seemed to be Declarations,  
LambdaExps, and
ReferenceExps, and started looking in those places (mostly by adding  
print outs;
I get stuck in the weeds a lot of times if I try to do line-by-line  
jdb'ing).
The ReferenceExps all seemed to be right (as you noted), so then I  
started
putting more prints (including a few Thread.dumpStack()s) in  
LambdaExp#compile.

In this case, because I had two similar blocks, one which worked and one
which failed, I ran them one at a time, redirecting their output to  
files
and then diffed the files. (A side-by-side diff viewer like Meld or  
FileMerge
is handy for that.)

> Thanks everyone,
> Charles.

--
Jamison Hope
The PTR Group
www.theptrgroup.com