[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CL packages
>Gary King <firstname.lastname@example.org> writes:
> > To put it differently, how much of CL's package problem is due to
> > having a read-time? Are there other interactive languages with better
> > solutions?
As far as CL goes, you might want to have a look at some work that JPL's
Erann Gat has done on what he calls Locales--an alternative for
packages--which, coincidentally, he presented at last night's LA Lisp user
group meeting (an encore of his talk at the NYC lisp conference earlier
A couple of relevant quotes:
>3. Introduction to locales
>There is an alternative to the package design that solves some of these
>Rather than resolving namespace conflicts at read-time, it could instead
>at compile time. Instead of allowing symbols with the same print name to
>for different purposes, the same symbol could be used simultaneously for
>multiple purposes. Rather than having one string "foo" map onto two different
>identifiers P1::FOO and P2::FOO depending on the value of *package*, we could
>instead have the single symbol FOO map onto two different bindings depending
>on the value of, say, *ENVIRONMENT*.
>Summary and Conclusions
>Locales are first-class environments that map symbols onto values. They were
>previously implemented in the T dialect of Lisp, but have since then been
>forgotten. It turns out to be possible to implement locales entirely
>Common Lisp. Locales therefore can coexist with and complement the Common
>Lisp package facility. Because locales operate at compile time or run time
>than read time, they have more intuitive behavior in certain situations.
>Furthermore, locales can provide functionality that packages can't, like
>lexical scoping and unifying function and value namespaces. Finally, because
>locales are first-class, they can also provide dynamic scoping for
>as symbol property lists.
P.S. An alternative way of looking at Locales (i.e. not in the paper cited
above) was provided to me last night by David M. Siegel, who happened to be
at the meeting and who was summarizing some of Erann's discussion which I
missed. If I remember correctly, David suggested that basically Locales
gives you the ability to inherit namespaces (using a tree structure) and
that you also get the ability to have transaction semantics on the
namespaces (i.e. you get to abort and save changes).
His example was a program that puts up a dialog box. A child namespace is
created. The parent namespace might have some default values for the fields
of the dialog box which are inherited by the child. A user makes some
changes, so the child namespace overrides the parental values for those
variables. If the user aborts, the child namespace goes away, no change to
the parent. If the user saves, the child values are written back to the
In this example, the namespaces are acting like a stack of sorts, but in
more complex situations one could imagine a tree-structure instead.
Oh, and the top-level namespace could have *its* changes saved to an actual
database, which takes care of *its* transactional semantics. (I think Erann
suggested that you could also use this to do versioning, etc. but again, I
missed some of Erann's discussion, so don't quote me :-) ).