Re: Package initialisation in CL boot

[Charles Turner <chturne at gmail dot com>]

On 3 July 2012 23:12, Per Bothner <per@bothner.com> wrote:
> On 07/03/2012 02:38 PM, Charles Turner wrote:
>> I can't tell from reading the spec what DEFUN is supposed to do with
>> the symbol passed to it in terms of packages. It follows from common
>> sense that it should intern the symbol, as the typical use case is to
>> export some defined symbols, and by interning the symbol, you
>> guarentee that it will be at least accessible. So I've overriden
>> Lisp2#defun in CommonLisp to intern the symbols in the current
>> package, as I didn't want ELisp dumping it's forms in CL packages.
>> I've done a similar thing with defStdBlahBlah methods too.
>
> That doesn't seem right.  The *reader* interns the symbol, depending
> the current package and package prefixes.  The defun just sets the
> symbol-function of that symbol.

Thanks. I've got myself in a tangle whilst trying to make progress on this.

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

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.

So, to fix that problem, I could create a new method in Lisp2 that
takes a symbol as an argument to lookup, rather than trying itself,
and I could override Language#getSymbol in CommonLisp to get the
current package rather than the default namespace. 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?

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

Thanks for your time,
Charlie.