Re: Package initialisation in CL boot

[Helmut Eller <eller dot helmut at gmail dot com>]

On Thu, Jul 12 2012, Per Bothner wrote:

> On 07/12/2012 11:06 AM, Charles Turner wrote:
>>>> 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?
>>>
>>> The may work better if you just concentrate on getting
>>>    COMMON-LISP-USER::|java.lang.String|
>>> to work.
>>
>> What do you mean by this? 'CL-USER::|java.lang.String| does what it's
>> supposed to according to the spec now, but are you saying that the
>> unpacking of a ReferenceExp in Translator is an acceptable approach?
>
> It's what we do for Scheme, and it seems plausible to do the same
> or something similar for Common Lisp.
>
> Scheme uses SchemeCompilation#checkDefaultBinding to resolve the class.
>
> For Common Lisp it might be reasonable to use a separate package,
> for example:
>   class:|java.lang.String|
> It's a tradeoff: Convenience of using COMMON-LISP-USER vs better
> of the package system for namespace separation.  Helmut, what do you
> think?

I would use strings in this case:
 
 (invoke-static "java.lang.String" "whatEver") 

doesn't look so bad to me.


For type specifiers, the clean solution is IMO a type constructor, e.g.

(lambda (x)
  (declare (type (kawa:java-type "java.lang.String") x))
  ...)

if that's needed a lot a type abbreviation could be used:

  (deftype jstring () '(kawa:java-type "java.lang.String"))
  (lambda (x)
    (declare (type jstring x))
    ...)


The class:|java.lang.String| idea would probably need a rule like: every
symbol in the class package evaluates to the type which represent the
Java class of that name.  Sort of like symbols in the keyword package
evaluate to themselves.

Normally CL has no first class types and type specifiers are used
instead: one writes (typep x 'string) not (type x string).  Types and
classes are also distinct: (typep x (find-class 'string)) would also not
work.  Would class:|java.lang.String| automatically be a type, a class,
or both?

I guess keywords like :|java.lang.String| would work just as well for
invoke-static (not so well for type specifiers).

Thinking about it: keywords in CL are quite similar to Scheme symbols,
maybe one could exploit that somehow and use that annoying
EmptyNamespace thing to represent the keyword package.

Helmut