Re: Package initialisation in CL boot

[Charles Turner <chturne at gmail dot com>]

On 05/07/2012, Helmut Eller <eller.helmut@gmail.com> wrote:
> * Charles Turner [2012-07-04 15:55] writes:
>> 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.

Indeed. It's more convenient to use the defun that takes strings when
initialising the symbols though. So it seems like overriding
Language#getSymbol is the way to go.

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

Yeah, I don't think this is nice either. I think it would be much
cleaner if all the standard symbols were static final Symbol of
CommonLisp. So you would initialise them like static final Symbol CAR
= cl_package.export("CAR") where export would return the result of
Symbol.make("CAR") or similar after adding it the symbol table. I
suppose enums would work too, but perhaps they wouldn't be as
convenient to work with.

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

I'm lost myself! What I mean is that in getSymbol(), if the
current_package.find_symbol("NAME") returns CommonLisp.FALSE, then we
also need to check the default namespace because "NAME" might in fact
be referencing a Scheme symbol, and the Scheme symbols populate the
default namespace AFAICT. So I have this in CommonLisp:

  @Override
  public Symbol getSymbol (String name)
  {
    Object s = LispPackage.currentPackage.findSymbol(name.toUpperCase()).get(0);
    return (s != CommonLisp.FALSE) ? (Symbol) s : super.getSymbol(name);
  }

(findSymbol just check the external symbols of the current package,
followed by the internal symbols, followed by the external symbols of
all the imported packages. It returns a Values, hence the get(0) for
the symbol returned)

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

I think I understand, both symbols are interned by the reader, and the
intern method will find cl:car directly, and cl-user:car after a
search in the inheritance chain.

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

Of course! Thanks Helmut for all the help :-)

My current problem is that I'm doing the following for each standard
symbol in the initLisp method of CommonLisp (it's better abstracted in
methods, this is just to show the idea)

Symbol s = Symbol.make(LispPackage.CLNamespace, "CAR");
LispPackage.CLNamespace.exported.add(s, s.hashCode());

and so on. ADD is calling AbstractHashTable#put to place the name.
However, when I intern 'car from LispReader, it doesn't find the name,
despite it looking in the correct package's exported symbol table.
This time INTERN calls the Namespace#lookup method, which appears to
be searching the same data structure as PUT. So CAR was defined as
above in the CL package, and I start lisp in the CL-USER package. I've
traced the execution path in the debugger, it correctly finds the CL
package in CL-USER's import list, but for some reason the symbols are
not CL's external table now...