This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
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