Re: Package initialisation in CL boot

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

* Charles Turner [2012-07-04 15:55] writes:

> We have lisp packages, which maintain their symbol tables using
> Namespace. Namespaces are linked to Environments by their get(Symbol)
> method, which looks symbols up in the "no property" environment
> mapping.

I'm not sure why Namespaces are linked to Environments.  In practice
this just seems to be the global Environment.

> So namespaces manage the name<->symbol mapping, and
> environments the symbol<->value mapping. Environments have different
> properties for function space lookups.
>
> So to confirm I understand:
>
> (defun car (x) (...))
>
> we want this exported in the CL package, so assume that's the current
> one. The reader interns CAR, it's not accessible so it created. It
> returns {COMMON-LISP}:CAR (this external representation is another
> problem, see below). The reader does similar things for DEFUN and X,
> where {COMMON-LISP}:DEFUN has a function binding assume, and
> {COMMON-LISP}:X has just been interned.

So far so good.

> DEFUN sets the function binding of {COMMON-LISP}:CAR to ... by using
> Environment#define with EnvironmentKey.FUNCTION property. However,
> DEFUN uses Lisp2#getSymbol to look {COMMON-LISP}:CAR up. It tries to
> find it in the default namespace, which has nothing to do with the CL
> packages.

There seem to be two different versions of Lisp2#defun.  I guess you're
talking about the one that takes Strings as argument.  Yes, indeed the
Namespace.getDefault stuff doesn't make sense for Common Lisp.

> So, to fix that problem, I could create a new method in Lisp2 that
> takes a symbol as an argument to lookup,

I think there is already a version of Lisp2#defun that takes Symbols.

> rather than trying itself,
> and I could override Language#getSymbol in CommonLisp to get the
> current package rather than the default namespace.

Hmm.. yes I guess using the current package (as in *package*) would make
some sense during loading, because many symbols will be interned in that
package.

OTOH, using string literals in Java code to refer to symbols will always
be problematic.  I was wondering if Java enums can be used instead of
string literals.

> This of course
> points to more cross language problems, as to access Scheme code, I
> would have to also check the default namespace. Does this should like
> a reasonable way to proceed?

You lost me here.  I don't understand the problem with Scheme code.

> So if it is, assume we're now in the CL-USER package evaluating (car '())
>
> The reader interns CAR as usual, it returns the symbol with the
> correct function binding in package CL. 

(eq 'cl-user:car 'cl:car) => t because the CL-USER package (usually)
uses the CL package.  It's correct what you're saying, but maybe you are
a bit confused how 'CL-USER:CAR gets the correct function binding.

> Translator#rewrite finds the
> symbol in the current environment using the FUNCTION property. Am I
> loosing my mind or is this how things should work?

Sounds sane to me.

> I'm hoping with the
> change above {COMMON-LISP}:CAR will end up in the current environment,
> not some newly interned symbol from the default namespace.
>
> The external representation of symbols poses another "where do I do
> this" problem. Symbol#toString is currently in charge of the
> {PREFIX}:name business. I don't want that for CL, but it doesn't seem
> sensible to try and subclass Symbol, and it seems inefficient to
> special case Symbol#toString to output a different representation
> based on the current language, so what which method would you chose?

The Lisp printer is usually in charge of this.  I think
DisplayFormat#writeSymbol is the right place to fix it.

Helmut