Re: GSOC | Extending Common Lisp support

[Charles Turner <chturne at gmail dot com>]

On 17 June 2012 01:42, Per Bothner <per@bothner.com> wrote:
> I think I've missed some of the previous discussion, but this is
> not Common Lisp syntax. ÂIt should be:
>
> Â(export 'test::A 'test)

Yeah, I was trying to get some package functionality implemented
before I tackled the reader.

> The package prefix is only used by the Lisp reader (and printer).
> It does not appear in any internal data structures, except as the name
> of a package (and then with no colons).

It seems to appear in the data structure SymbolRef (implicity via
Symbol), with colons n' all. My FIND-SYMBOL function is using the
Namespace#lookupInternal method, which will give you back a Symbol
with the package prefix, colon, and name.

If the reader worked, what would the steps of this be:

(export 'test::a 'test)

Would the reader make sure test exists, then lookup 'a in its internal
table, creating a new symbol if one didn't already exist? So then what
would export's first parameter be? The symbol 'a whose hashCode would
match 'a in test, but not say in an 'a in cl-user? Because currently
I'm having to deal with the raw "test::a" in my code.

On the reader issue, I don't follow the logic in readAndHandleToken.
If the reader sees one colon (indicating an external lookup), then
packageMarker is the position of that colon in the input stream. If it
sees two colons (indicating an internal lookup), packageMarker is set
to -1, its default having seen no colons. So it seems that the reader
doesn't distinguish two-colons from seeing no colons! But for the case
of one colon, I can see how do add plumbing into LispPackage to lookup
the package prefix, and then do an external lookup on that package for
the symbol name. Does that match what you envisioned would be changed
to readAndHandleToken?

Thanks for the help,
Charlie.