Re: Package initialisation in CL boot

[Charles Turner <chturne at gmail dot com>]

On 9 July 2012 17:08, Jamison Hope <jrh@theptrgroup.com> wrote:
> 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 back online, just barely. First thing I did was submit my
evaluation! Thanks.

> 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")));

I will experience the same problems unfortunately. I understand what
you saying though, for now I'm using the names in EmptyNamespace for
these reader macros.

> 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.

Yeah, that's what I meant before. I made a new CL package called KAWA,
whose exported symbol table is just the EmptyNamespace. Then I made
CL-USER inherit from KAWA. I think it's better to not have CL inherit
from KAWA so that if a user wants to be unpolluted from the other
languages, they can just inherit from CL, but it's seems like a
reasonable default to drop the user in a package that is "polluted",
even though it might cause a few surprises.

>> 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?

Cond appears to work OK:

#|kawa:1|# (cond ((= 1 2) 'no) (else 'yes))
{COMMON-LISP}:yes

>> 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.

It can't account for the arbitrary ClassType's. I've sunk a lot of
time into trying to get case folding to work in a sane way, but I just
can't see the light. For instance, how would this even work?

(invoke-static some.java.ClassName 'whatEver)

The reader, if using case folding, presents the system with a fold
like SOME.JAVA.CLASSNAME and a method WHATEVER. How will it know what
the correct case is when it comes time to lookup the Java code? I'll
have to look into how ABCL gets around this. I did investigate the
possibility of postponing folding until later in the compiler, so I
could check things like type names. This worked, sorta, but I
abanonded it because I'd convinced myself after a day or two that it
can't be the right method. Currently I've backtracked to just having
the classtype problems, and populating the standard types like
integer, pair, etc into EmptyNamespace at boot time.

The problem for now is, how to handle something like
COMMON-LISP-USER::java.lang.String as a type name. Translator#exp2Type
returns an error saying unknown type name because this symbol gets
turned into a ReferenceExp by rewrite_car in exp2Type. One way around
this would be to unpack the ReferenceExp in exp2Type (in Translator
where is checks texp instanceof ReferenceExp) and perform a
rewrite(((ReferenceExp) texp).getName()) to get the ClassType when
it's appropriate, then wrap that up in a QuoteExp and return it.
Doesn't seem "right" though, any ideas on a better approach?

> 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.

That's reassuring (?) :-)

Thanks for the help,

Charlie.