Re: CL packages

[David Cohen <address@hidden>]

>
>Gary King <gwking@cs.umass.edu> 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 
this month):

http://www.flownet.com/gat/locales.pdf

A couple of relevant quotes:

>3. Introduction to locales
>There is an alternative to the package design that solves some of these 
>problems.
>Rather than resolving namespace conflicts at read-time, it could instead 
>be done
>at compile time. Instead of allowing symbols with the same print name to 
>be used
>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*.

and:

>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 
>largely
>forgotten. It turns out to be possible to implement locales entirely 
>within ANSI
>Common Lisp. Locales therefore can coexist with and complement the Common
>Lisp package facility. Because locales operate at compile time or run time 
>rather
>than read time, they have more intuitive behavior in certain situations.
>Furthermore, locales can provide functionality that packages can't, like 
>proper
>lexical scoping and unifying function and value namespaces. Finally, because
>locales are first-class, they can also provide dynamic scoping for 
>applications such
>as symbol property lists.

___
DC

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

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