Re: GSOC | Extending Common Lisp support

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

* Charles Turner [2012-06-13 21:32] writes:

> On 13 June 2012 21:44, Helmut Eller <eller.helmut@gmail.com> wrote:
>> [snip]
>> Currently signal would just turn any error into an RuntimeException and
>> throw it, but in the future it could invoke the current exception
>> handler.
>
> Thanks for the elucidation. I will follow your strategy apropos
> conditional restarts.

Maybe also ask Per how he wants to deal with it.

>> I think syms can also contain strings, not just symbols.
>
> Hm, the CLHS has this to say:
>
> "export symbols &optional package
> symbols---a designator for a list of symbols.
>
> package---a package designator. The default is the current package."
>
> So I think this must contain just symbols.

Ah, yes right: only symbols.  But it can also be a single symbol and not
a list; maybe that's handled elsewhere.

>> I think this should be: usedBy = pkg.importing
>
> I'm not sure what the comment above importing is referring to when it
> mentions the CL "used-by list". I can't find "used-by" in the CLHS
> glossary.

I guess it comes from the "reference implementation" in CMUCL or SBCL
where this is called %used-by-list and %use-list.

> But w.r.t this point, the bit of code you mention was
> intended to search the inheritance hierarchy for name conflicts. I was
> under the impression that "imported" was the set of packages this
> package inherits from, so in a definition like:
>
> (make-package "a" ... :use '("b", "c"))
>
> when one exports a symbol from "a", you need to check if the symbol is
> exported from "b" and "c". When processing :use, I have been putting
> "b" and "c" into the imported list. What am I missing here?  My
> interpretation of "importing" is the list of packages that import this
> package.

I also think that imported/importing is as you describe.  But exporting
a symbol from package "a" may cause conflicts in those packages that use
"a" not in those package that "a" uses, right?   E.g. if we have

(make-package "d" ... :use '("a"))
(export 'c:foo "a") 

Then we need to check that no other symbol than c:foo with name foo is
accessible in "d".

> Probably getting ahead of myself, but in thinking about what
> "importing" is for, I conjecture it might be intended to build a
> resource allocation graph of sorts, for more sophisticated
> synchronization analysis. I've blithely disregarded such issues at
> this stage, but I imagine it will bite me in the arse later.

Sounds almost like science fiction to me :-).  The point of importing is
that one can write FOO instead of BAR::FOO without necessarily making
all other exported symbols from BAR accessible.  That's pretty much all
there is to it.

Helmut