This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Package initialisation in CL boot
On Jul 8, 2012, at 2:47 PM, Charles Turner wrote:
My internet service has once again been cut off due to the weather
we're experiencing. The ISP said it would take three working days on
Friday maximum, but they've lied before. This is probably sounding
like an excuse not to do my GSOC work, I can only get my ISP to send a
letter confirming the fault if that would help. I am working, but
progress is slower due to the problems mentioned below.
Don't worry, I believe you. I saw pictures of the Olympic torch being
carried through the rain! Don't forget, though, that you've got to
submit your GSOC mid-term evaluation this week. The FAQ [1] says "Any
student who does not submit an evaluation by the evaluation deadline
will fail that evaluation, regardless of the grade the mentor gives
the student."
I think you deserve to pass, so make sure you find a way to get that
done.
------
I'm having great difficulities modifying the reader the intern symbols
correctly for CL. I want the reader to look for symbols as per the CL
spec so that I can move on from the package stuff and possibly get
around to the problems with DEFMACRO.
------
I would like the reader to intern all symbols in the current package
as it
should, so I made my start in LispReader#readAndHandleToken
if (Language.currentLanguageIs("CommonLisp"))
{
return (Symbol) LispPackage.currentPackage.intern(symname).get(0);
}
else
{
return rtable.makeSymbol(symname);
}
That seems OK, but I wonder if it's better to modify
ReadTable#makeSymbol?
Note that ReaderDispatch#create maps #' to FUNCTION with
tab.set('\'', new ReaderQuote(rtable.makeSymbol("function")));
The immediate problem is that it would only look in the inheritance
hierachy of the current package, but that means we can't access the
Scheme ecosystem, since the Scheme symbols are placed in the empty
namespace. One possibility is to have package CL use the default
namespace, another is to modify LispPackage#intern so that failed
lookups in a given package chain are retried in the empty
namespace. If that still fails, I intern the symbol in the current
package.
I have a feeling we'll want to keep the CL package and the
EmptyNamespace
pseudo-package as distinct, if only because the CL package is supposed
to be locked with its 978 symbols.
[At this point I recognize a complication with my makeSymbol suggestion
above: currently the reader turns backquotes and commas into quasiquote
and unquote expressions, but AFAICT in CL there's no standard symbol
UNQUOTE or QUASIQUOTE. I don't think it's worthwhile to totally change
how those are read, though, so I guess we'll have to have 980 symbols.]
It makes sense to me to treat the empty namespace as a fallback; it's
akin to how lookup works in C++ (without it you wouldn't be able to
reference C functions or variables). Or perhaps another option might
be to make EmptyNamespace a full-fledged LispPackage and have the
CL package inherit from it? Then maybe the normal lookup chain would
be enough.
This yields more problems though, because certain "symbols" are not
registered in the empty namespace but are required to have an empty
namespace to work properly, like the "..." symbol used in
define-syntax. If the above solution is left to it's own devices,
"..." gets interned in CL-USER the first time it's seen, and then your
macros break, because the transformers don't know what to do with
{CL-USER}:.... I've special cased it in the reader, but this isn't
nice.
Hmm, that does seem unfortunate. Does that also happen with literals
in syntax-rules or syntax-case macros, such as "else" or "=>" in
(Scheme's) cond?
The next problem is types. Type names also aren't present in the empty
namespace, so type lookups fail because the type system can't find
things like {COMMON-LISP-USER}:integer on the first go. Translator
does in fact intern such occurances into the empty namespace, so a
second try does in fact work. My work around this is to simply add the
type names into the empty namespace. I would plan to export the export
the names through CL, so that once the CL package is locked, you can't
redefine the type names.
Your workaround is probably fine for now.
In summary, this approach seems to produce problem after problem whose
solutions become kludgier and kludgier. I must be approaching this all
wrong. Any pointers?
As we've already noticed with #!null/#!void/NIL/()/#f, some degree of
kludginess is going to be unavoidable when attempting to meld languages.
Unfortunately (?), I think you're probably already on the right track.
Thanks for the your time,
Charlie.
Don't forget to submit your evaluation! (That goes for me, too.)
-Jamie
[1] http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs#evaluations
--
Jamison Hope
The PTR Group
www.theptrgroup.com