Re: Package initialisation in CL boot

[Charles Turner <chturne at gmail dot com>]

My internet service has once again been cut off due to the weather
we're experiencing. The ISP said it would take three working days on
Friday maximum, but they've lied before. This is probably sounding
like an excuse not to do my GSOC work, I can only get my ISP to send a
letter confirming the fault if that would help. I am working, but
progress is slower due to the problems mentioned below.
------

I'm having great difficulities modifying the reader the intern symbols
correctly for CL. I want the reader to look for symbols as per the CL
spec so that I can move on from the package stuff and possibly get
around to the problems with DEFMACRO.
------

I would like the reader to intern all symbols in the current package as it
should, so I made my start in LispReader#readAndHandleToken

if (Language.currentLanguageIs("CommonLisp"))
{
  return (Symbol) LispPackage.currentPackage.intern(symname).get(0);
}
else
{
  return rtable.makeSymbol(symname);
}

The immediate problem is that it would only look in the inheritance
hierachy of the current package, but that means we can't access the
Scheme ecosystem, since the Scheme symbols are placed in the empty
namespace. One possibility is to have package CL use the default
namespace, another is to modify LispPackage#intern so that failed
lookups in a given package chain are retried in the empty
namespace. If that still fails, I intern the symbol in the current
package.

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.

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.

In summary, this approach seems to produce problem after problem whose
solutions become kludgier and kludgier. I must be approaching this all
wrong. Any pointers?

Thanks for the your time,
Charlie.