Hi everybody,
Here is a question of understanding: There are several constructs in
Common Lisp that define named entities (not an established term, just
made up on the spot). I am thinking about classes that you need to name
in the defclass macro, or packages that you need to name when you do a
defpackage or make-package.
So names that have been defined once need to retain the definitions
associated with their symbols until they are explicitly uninterned, or
the respective definitions are explicitly made unbound. Even if at times
the names are not referenced in an image, they need to retain their
definitions because those names can be read again some time in the
future.
However, the uniqueness of gensyms is not captured by their names. If
you happen to type the name again of an already existing gensym, you
still get a new symbol. Consequentially, when I use a gensym as the name
of such an entity, can I rely on garbage collection to take care of
associated definitions? My understanding is that, as soon as the gensym
is gc'ed after I lose my references to it, the runtime system should
delete the associated definitions.
Do I have a correct understanding of these matters? For example, do
existing CL implementations automatically call delete-package on a
package that is identified by a gensym, as soon as the gensym is gc'ed?
Thanks for any kind of help in advance,
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
On Wed, Mar 26, 2003 at 12:00:47AM +0100, Pascal Costanza wrote:
> Do I have a correct understanding of these matters? For example, do
> existing CL implementations automatically call delete-package on a
> package that is identified by a gensym, as soon as the gensym is gc'ed?
DEFPACKAGE only uses the symbol for its name string, so it doesn't
matter what happens to the symbol afterwards.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey3u1drghv8.fsf@cley.com>
* Pascal Costanza wrote:
> However, the uniqueness of gensyms is not captured by their
> names. If you happen to type the name again of an already existing
> gensym, you still get a new symbol. Consequentially, when I use a
> gensym as the name of such an entity, can I rely on garbage
> collection to take care of associated definitions? My understanding
> is that, as soon as the gensym is gc'ed after I lose my references
> to it, the runtime system should delete the associated definitions.
No, you can't. For instance something like a class undoubtedly exists
at least as one of the subclasses of some other class, and thus won't
be GCd. You'd have to do something to remove all those
references. Packages are not named by symbols in any case, but if they
were then they exist on the `list of all packages' that
LIST-ALL-PACKAGES returns, as well as possibly as the home package of
symbols &c &c.
If there are *no references* to an object then it might be GCd
(whatever that might mean for the implementation), but while
references exist it will not be.
In the case of something like a function named by a gensym which is
not otherwise referenced then, sure, it might be GCd, if the gensym
is, which is exactly the case of no references.
But in general there is nothing magic about symbols naming things:
that's just one of the ways some object can be referenced.
--tim
Pascal Costanza <········@web.de> writes:
> Do I have a correct understanding of these matters? For example, do
> existing CL implementations automatically call delete-package on a
> package that is identified by a gensym, as soon as the gensym is
> gc'ed?
No, this is not right. There is nothing special about gensyms from the
point of view of GC. No functions, delete-package or other, will be
called by the GC process. GC don't "do" _anything_. At least in
principle. One GC strategy could be "assume we won't run out of space
before armageddon". Another, "periodically delete all objects that
can't be reached". Or, "periodically rescue only those objects that
can be reached" is often used in practice. If you have a package named
by a gensym, is that gensym reachable? Typically, the mechanism used
by (find-package <name>) is a hash-table mapping names to the package
objects. In that case, the gensym would be reachable e.g. by maphash
over that hash-table, and thus eligible for not being deleted, or to
be rescued, respectively.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Pascal Costanza <········@web.de> writes:
>
> > Do I have a correct understanding of these matters? For example, do
> > existing CL implementations automatically call delete-package on a
> > package that is identified by a gensym, as soon as the gensym is
> > gc'ed?
>
> No, this is not right. There is nothing special about gensyms from the
> point of view of GC.
Right. There is, in point of fact, no such thing as a gensym as a type
of thing.
Gensym makes an uninterned symbol, sometimes informally called a gensym.
But there are other ways for symbols to become uninterned, and
it would be quite unfortunate if I could do
(intern 'xyzzy)
...
(make-package 'xyzzy)
...
(unintern 'xyzzy)
and later find that my entire XYZZY package had disappeared.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> Gensym makes an uninterned symbol, sometimes informally called a gensym.
> But there are other ways for symbols to become uninterned, and
> it would be quite unfortunate if I could do
>
> (intern 'xyzzy)
> ...
> (make-package 'xyzzy)
> ...
> (unintern 'xyzzy)
>
> and later find that my entire XYZZY package had disappeared.
Well, I have an application in which such a behaviour would be exoctly
what I need. My current solution is to "bind" the packages in question
to objects and delete the packages in object finalizers that are called
by the garbage collector. However, this is not portable.
Anyway, thanks to everybody who contributed answers to my original
posting.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey3znni9xzu.fsf@cley.com>
* Pascal Costanza wrote:
> Well, I have an application in which such a behaviour would be exoctly
> what I need. My current solution is to "bind" the packages in question
> to objects and delete the packages in object finalizers that are called
> by the garbage collector. However, this is not portable.
I think that if you're doing this then you are probably doing
something very peculiar. Packages really aren't for that! If you
want a name->object map use a hashtable...
One application I can think of where you might want to do this, or
something like it, is establishing temporary scratch packages for code
that needs to read things it might not trust. But there are a lot of
other problems with this in any case - mostly that you can't easily
stop someone poking around in other packages by known-package::symbol
type syntax.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Pascal Costanza wrote:
>
> > Well, I have an application in which such a behaviour would be exoctly
> > what I need. My current solution is to "bind" the packages in question
> > to objects and delete the packages in object finalizers that are called
> > by the garbage collector. However, this is not portable.
>
> I think that if you're doing this then you are probably doing
> something very peculiar. Packages really aren't for that! If you
> want a name->object map use a hashtable...
It's the implementation of a JVM in CL I am currently implementing. CL's
packages are very suitable for implementing aspects of Java's class
loader architecture. (In Java, package names are not unique in general.
Class loaders define namespaces, and everything else is embedded in
those class loaders. So in effect, you can have more than one instance
of the same package in a JVM. Of course, I would like to reuse CL's
package mechanism for implementing Java packages, but I would also like
to make sure that they are gc'ed, just as class loaders are gc'ed in
Java.)
BTW, a minor correction: In the previous post, kmp talked about
uninterned symbols and the packages named by them that should not be
gc'ed. Of course that's the desired behaviour. I have mistaken
uninterned for gc'ed symbols.
BTWBTW, aren't the locales of T the kind of garbage-collected packages I
am looking for?
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Pascal Costanza <········@web.de> writes:
> BTW, a minor correction: In the previous post, kmp talked about
> uninterned symbols and the packages named by them that should not be
> gc'ed. Of course that's the desired behaviour. I have mistaken
> uninterned for gc'ed symbols.
No, you were right about that, uninterned symbols are in all
likelihood gc'd. What you are wrong about is that symbols name
packages. They don't -- packages are named by strings. From the
spec:
Function MAKE-PACKAGE
Syntax:
make-package package-name &key nicknames use => package
Arguments and Values:
package-name---a string designator.
[...]
The same goes for defpackage. People usually use symbols as the
string designators, but the first thing MAKE-PACKAGE does with those
symbols is call STRING on them.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> No, you were right about that, uninterned symbols are in all
> likelihood gc'd.
Huh? Given the following code.
(defvar *v* 'sym)
(unintern *v*)
I don't expect #:sym to be gc'ed afterwards because *v* is still
referring to it. Or am I really wrong in this regard?
> What you are wrong about is that symbols name
> packages. They don't -- packages are named by strings. From the
> spec:
>
> Function MAKE-PACKAGE
> Syntax:
> make-package package-name &key nicknames use => package
> Arguments and Values:
> package-name---a string designator.
> [...]
>
> The same goes for defpackage. People usually use symbols as the
> string designators, but the first thing MAKE-PACKAGE does with those
> symbols is call STRING on them.
OK - I should have looked that up first. Why are things specified like
that?
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
In article <······························@news.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
>In article <···············@conquest.OCF.Berkeley.EDU>,
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
>> No, you were right about that, uninterned symbols are in all
>> likelihood gc'd.
>
>Huh? Given the following code.
>
>(defvar *v* 'sym)
>(unintern *v*)
>
>I don't expect #:sym to be gc'ed afterwards because *v* is still
>referring to it. Or am I really wrong in this regard?
You're correct. He said "in all likelihood", presumably assuming that
nothing was left still referencing the symbol. Often, the reason you
unintern is to remove the final reference to the symbol by the Lisp system,
after you've removed all the application's references, in order to allow it
to be GC'ed.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Pascal Costanza <········@web.de> writes:
> In article <···············@conquest.OCF.Berkeley.EDU>,
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > No, you were right about that, uninterned symbols are in all
> > likelihood gc'd.
>
> Huh? Given the following code.
>
> (defvar *v* 'sym)
> (unintern *v*)
>
> I don't expect #:sym to be gc'ed afterwards because *v* is still
> referring to it. Or am I really wrong in this regard?
Of course! The GC only collects things that have no more (hard)
references, thank goodness.
> > What you are wrong about is that symbols name
> > packages. They don't -- packages are named by strings. From the
> > spec:
> >
> > Function MAKE-PACKAGE
> > Syntax:
> > make-package package-name &key nicknames use => package
> > Arguments and Values:
> > package-name---a string designator.
> > [...]
> >
> > The same goes for defpackage. People usually use symbols as the
> > string designators, but the first thing MAKE-PACKAGE does with those
> > symbols is call STRING on them.
>
> OK - I should have looked that up first. Why are things specified like
> that?
Because the alternative makes no sense. Think about it:
(make-package 'foo) => #<The FOO package>
(make-package 'bar) => #<The BAR package>
(eq 'foo::alpha 'bar::alpha) => nil
(make-package 'foo::alpha) => #<The ALPHA package>
(make-package 'bar::alpha) => #<The ALPHA package>
(eq * **) => ; what?
What happens when the reader comes across "alpha::beta", which "ALPHA"
package is BETA in?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@apocalypse.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote:
>Pascal Costanza <········@web.de> writes:
>> > The same goes for defpackage. People usually use symbols as the
>> > string designators, but the first thing MAKE-PACKAGE does with those
>> > symbols is call STRING on them.
>>
>> OK - I should have looked that up first. Why are things specified like
>> that?
>
>Because the alternative makes no sense. Think about it:
>
> (make-package 'foo) => #<The FOO package>
> (make-package 'bar) => #<The BAR package>
> (eq 'foo::alpha 'bar::alpha) => nil
> (make-package 'foo::alpha) => #<The ALPHA package>
> (make-package 'bar::alpha) => #<The ALPHA package>
> (eq * **) => ; what?
>
>What happens when the reader comes across "alpha::beta", which "ALPHA"
>package is BETA in?
If we had decided to name pages using symbols rather than strings, we
presumably would have provided a way to distinguish these. It would
probably be something like:
(make-package 'foo::alpha) => #<The FOO::ALPHA package>
(make-package 'bar::alpha) => #<The BAR::ALPHA package>
and you would type "foo::alpha::beta" or "bar::alpha::beta" to refer to
symbols in those packages.
BTW, Lisp Machine Lisp had syntax like this, but it was used for its
hierarchical package system. When Common Lisp was being designed, they
decided to generalize the package system by removing the hierarchy and
adding USE-PACKAGE (in the hierarchical system, a package implicitly used
the packages above it in the hierarchy).
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote:
[...]
> >Because the alternative makes no sense. Think about it:
> >
> > (make-package 'foo) => #<The FOO package>
> > (make-package 'bar) => #<The BAR package>
> > (eq 'foo::alpha 'bar::alpha) => nil
> > (make-package 'foo::alpha) => #<The ALPHA package>
> > (make-package 'bar::alpha) => #<The ALPHA package>
> > (eq * **) => ; what?
> >
> >What happens when the reader comes across "alpha::beta", which "ALPHA"
> >package is BETA in?
>
> If we had decided to name pages using symbols rather than strings, we
> presumably would have provided a way to distinguish these. It would
> probably be something like:
>
> (make-package 'foo::alpha) => #<The FOO::ALPHA package>
> (make-package 'bar::alpha) => #<The BAR::ALPHA package>
>
> and you would type "foo::alpha::beta" or "bar::alpha::beta" to refer to
> symbols in those packages.
Actually, in an early draft of CLTL that got changed before we went to print,
there was a PACKAGE package, and symbols were indeed the name of packages.
When you wrote A:B it meant PACKAGE:A:B (everything bottomed out at the
PACKAGE package). And you could make a PACKAGE:A:B:C:D which meant to get
the symbol D in the package named by the symbol C in the package named by
the symbol B in the package named by the symbol A in the PACKAGE package,
which was the toplevel registry.
This stuff just vanishes between two drafts, and I was not privvy to the
discussion that caused it, but I've often wondered if there was a real
technical problem or if people just thought this to be too much hair.
Maybe everyone would have still fought for the root package names.
That's why I advocate everyone use package names like I use, with their
organization or company or something built into them, as in
com.hypermeta.whatever
> BTW, Lisp Machine Lisp had syntax like this, but it was used for its
> hierarchical package system. When Common Lisp was being designed, they
> decided to generalize the package system by removing the hierarchy and
> adding USE-PACKAGE (in the hierarchical system, a package implicitly used
> the packages above it in the hierarchy).
(I didn't remember it had such syntax. I do remember the hierarchical package
system.)
Much later, I also added a syntax to Symbolics Common Lisp that allowed
the notion of "package universes" to be associated with a syntax, so that
ANSI-CL:::USER::X mean what Zetalisp (the earlier package system) would have
called FUTURE-COMMON-LISP-USER::X, ZL:::USER:X meant ZL-USER:X,
and CL:::USER::X meant CL-USER::X. Within any of these syntaxes, as was the
normal case, the syntax prefix is not normally needed and most people never
bother with it at all. But it's an occasionally useful escape.
I do think it was a design error that we made a flat namespace, but I find
the use of 'dotted' package names mostly makes up for it.
Kent M Pitman <······@world.std.com> writes:
> Barry Margolin <··············@level3.com> writes:
>
> > In article <···············@apocalypse.OCF.Berkeley.EDU>,
> > Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote:
> [...]
> > >Because the alternative makes no sense. Think about it:
> > >
> > > (make-package 'foo) => #<The FOO package>
> > > (make-package 'bar) => #<The BAR package>
> > > (eq 'foo::alpha 'bar::alpha) => nil
> > > (make-package 'foo::alpha) => #<The ALPHA package>
> > > (make-package 'bar::alpha) => #<The ALPHA package>
> > > (eq * **) => ; what?
> > >
> > >What happens when the reader comes across "alpha::beta", which "ALPHA"
> > >package is BETA in?
> >
> > If we had decided to name pages using symbols rather than strings, we
> > presumably would have provided a way to distinguish these. It would
> > probably be something like:
> >
> > (make-package 'foo::alpha) => #<The FOO::ALPHA package>
> > (make-package 'bar::alpha) => #<The BAR::ALPHA package>
> >
> > and you would type "foo::alpha::beta" or "bar::alpha::beta" to refer to
> > symbols in those packages.
>
> Actually, in an early draft of CLTL that got changed before we went to print,
> there was a PACKAGE package, and symbols were indeed the name of packages.
> When you wrote A:B it meant PACKAGE:A:B (everything bottomed out at the
> PACKAGE package). And you could make a PACKAGE:A:B:C:D which meant to get
> the symbol D in the package named by the symbol C in the package named by
> the symbol B in the package named by the symbol A in the PACKAGE package,
> which was the toplevel registry.
Okay, this makes sense. Reading Barry's reply, that sounded awefully
circular -- having a PACKAGE package (presumably named by
PACKAGE:PACKAGE ?) takes care of the discomfort I was feeling.
> I do think it was a design error that we made a flat namespace, but I find
> the use of 'dotted' package names mostly makes up for it.
I just wish there was a portable way of using facilities from dotted
packages conveniently, without USE-PACKAGE'ing them. Like
package-local nicknames.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey3d6kbw26r.fsf@cley.com>
* Thomas F Burdick wrote:
> I just wish there was a portable way of using facilities from dotted
> packages conveniently, without USE-PACKAGE'ing them. Like
> package-local nicknames.
Have a look at my conduits/hierarchal packages stuff, which now
supports this. It *should* work in any system which (a) goes through
FIND-PACKAGE everywhere and (b) allows you to redefine it. The actual
HP implementation is originally Franz's, the reason you need conduits
too is because it already defines its own DEFPACKAGE macro and I
didn't want two...
You can say, for instance:
(in-package :org.tfeb.clc-user)
(defpackage :com.cley.obscure.system
(:use :org.tfeb.clc)
(:alias (:cl :org.tfeb.clc)))
And now, if *PACKAGE* is COM.CLEY.OBSCURE.SYSTEM, CL:x is read as
ORG.TFEB.CLC:x (which for most x is the same symbol, in this case!)
I think CMUCL has its own HP system (I in fact never use the relative
names anyway), so presumably it would need to implement it itself,
although I think just layering my hack on top of it does work, albeit
redundantly.
This is not really carefully tested (read: I've never used it for the
package aliasing features).
--tim
Tim Bradshaw <···@cley.com> writes:
> * Thomas F Burdick wrote:
>
> > I just wish there was a portable way of using facilities from dotted
> > packages conveniently, without USE-PACKAGE'ing them. Like
> > package-local nicknames.
>
> Have a look at my conduits/hierarchal packages stuff, which now
> supports this. It *should* work in any system which (a) goes through
> FIND-PACKAGE everywhere and (b) allows you to redefine it. The actual
> HP implementation is originally Franz's, the reason you need conduits
> too is because it already defines its own DEFPACKAGE macro and I
> didn't want two...
>
> You can say, for instance:
>
> (in-package :org.tfeb.clc-user)
>
> (defpackage :com.cley.obscure.system
> (:use :org.tfeb.clc)
> (:alias (:cl :org.tfeb.clc)))
>
> And now, if *PACKAGE* is COM.CLEY.OBSCURE.SYSTEM, CL:x is read as
> ORG.TFEB.CLC:x (which for most x is the same symbol, in this case!)
>
> I think CMUCL has its own HP system (I in fact never use the relative
> names anyway), so presumably it would need to implement it itself,
> although I think just layering my hack on top of it does work, albeit
> redundantly.
>
> This is not really carefully tested (read: I've never used it for the
> package aliasing features).
You might also want to look at our offering as well:
http://www.franz.com/support/documentation/6.2/doc/packages.htm#hier-packs-1
available in Allegro CL 6.2.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey3adffoyyc.fsf@cley.com>
* Duane Rettig wrote:
> You might also want to look at our offering as well:
> http://www.franz.com/support/documentation/6.2/doc/packages.htm#hier-packs-1
I should point out that my HP code (though not conduits) is based on
the stuff Franz have made available (I think it's based on the 6.0 or
6.1 code).
However, I think (from a brief glance at the page referenced above)
that the per-package aliases stuff is *not* something that the Franz
implementation currently does - it only makes it possible to refer to
packages with relative `pathnames' not essentially to provide
arbitrary symbolic links to packages.
Both things are useful, of course!
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> I think CMUCL has its own HP system (I in fact never use the relative
Tim> names anyway), so presumably it would need to implement it itself,
It is, basically, the sample implementation from Franz.
Ray
Barry Margolin wrote:
> If we had decided to name pages using symbols rather than strings, we
> presumably would have provided a way to distinguish these. It would
> probably be something like:
>
> (make-package 'foo::alpha) => #<The FOO::ALPHA package>
> (make-package 'bar::alpha) => #<The BAR::ALPHA package>
>
> and you would type "foo::alpha::beta" or "bar::alpha::beta" to refer to
> symbols in those packages.
>
> BTW, Lisp Machine Lisp had syntax like this, but it was used for its
> hierarchical package system. When Common Lisp was being designed, they
> decided to generalize the package system by removing the hierarchy and
> adding USE-PACKAGE (in the hierarchical system, a package implicitly used
> the packages above it in the hierarchy).
This points to a possible explanation: When child packages implicitly
refer to parent packages, this potentially makes code harder to
refactor. When they don't, it's not so clear what the advantages of a
hierarchical package system really are.
BTW, Java's packages are not really hierarchical either. There's no
implicit import of identifiers, and all "top-level" identifiers are
always fully qualified within Java class files (so for example it's
always java.lang.String instead of String). So, the only real advantages
of Java's packages are the globally unique naming scheme, and the direct
mapping between package names and directory names. The latter doesn't
scale very well, and is better handled by a make/defsystem facility I guess.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <············@f1node01.rhrz.uni-bonn.de>,
Pascal Costanza <········@web.de> wrote:
>Barry Margolin wrote:
>
>> If we had decided to name pages using symbols rather than strings, we
>> presumably would have provided a way to distinguish these. It would
>> probably be something like:
>>
>> (make-package 'foo::alpha) => #<The FOO::ALPHA package>
>> (make-package 'bar::alpha) => #<The BAR::ALPHA package>
>>
>> and you would type "foo::alpha::beta" or "bar::alpha::beta" to refer to
>> symbols in those packages.
>>
>> BTW, Lisp Machine Lisp had syntax like this, but it was used for its
>> hierarchical package system. When Common Lisp was being designed, they
>> decided to generalize the package system by removing the hierarchy and
>> adding USE-PACKAGE (in the hierarchical system, a package implicitly used
>> the packages above it in the hierarchy).
>
>This points to a possible explanation: When child packages implicitly
>refer to parent packages, this potentially makes code harder to
>refactor. When they don't, it's not so clear what the advantages of a
>hierarchical package system really are.
The hierarchical package system was intended to mirror application
organization. A sub-package would typically be used for a component of the
application that can't really stand on its own.
The hierarchical package system allowed two kinds of abbreviation:
1. You could refer to symbols in the ancestor packages without
qualification.
2. You could refer to symbols in descendant packages using a pathname
relative to the current package.
The example given in the Chineuals looked like this:
GLOBAL
|
/----------------------------------\
MACSYMA OWL
| |
------------- ---------
| | | | |
RISCH SIN INPUT INPUT DATABASE
MACSYMA might have some general symbols that are useful by all its
subpackages, and they can refer to them unqualified (this is similar to the
way CLOS, and most other OO systems, allows subclasses to refer to slots
and methods inherited from superclasses). RISCH and SIN might both have
functions named INTEGRATE; from within MACSYMA (including any of its
subpackages) you can refer to them as RISCH:INTEGRATE and SIN:INTEGRATE,
but from anywhere else you'd have to say MACSYMA:RISCH:INTEGRATE or
MACSYMA:SIN:INTEGRATE (much like relative pathnames in a file system).
CL doesn't have anything like the relative naming mechanism, but
USE-PACKAGE provides linkage between packages similar to the inheritance
from ancestors (except it's not transitive).
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Pascal Costanza <········@web.de> writes:
> BTWBTW, aren't the locales of T the kind of garbage-collected packages I
> am looking for?
It's long ago I read the T manual, but Oaklisp is a descendant of T
and has locales. These are even objects. Conceptually, locales could
exist solely as compile-time (or so) objects, like environment for the
process of macroexpansion, or lexical environments.
Locales don't have names so they have no uniqueness restriction like
packages. There's no FIND-LOCALE since there's no global list. For
your purpose, they behave like Emacs- and older Lisp's obarrays, which
the reader uses.
However, since in a JVM, you can have equal package names designating
different classes, CL packages are not a good way to represent these.
You don't need package-names defined by uninterned symbols (which I
believe is a misconception of yours anyway), you need either something
else as packages, or a
class-loader/namespace * java-package-designator -> unique-string-
for use as CL package-name.
If you really want to use packages, why don't you define functions:
1. class-loader/namespace * package-dotted-string -> package
2. or define a closure/method/slot hold by each class-loader which
holds the local java-package-dotted-string -> cl-package mapping?
An example:
(defun JVM-package-name (class-loader/namespace java-package-designator)
(concatenate 'string
"$"
(princ-to-string (unique-ID class-loader/namespace))
java-package-designator
"-JVM"))
;(JVM-package-name thiscl "javax.sql")
However, since there's a global list of packages, you cannot expect
them to die without help. But you can use your favourite
implementation of Lisp finalizers:
(FINALIZE this-class-loader
#'(lambda (x) (map nil #'delete-package
(class-loader-local-packages x))))
But that has other problems, since methods from one of these may still
be hold somewhere else, and they might still expect to get the package
for "javax.sql" in their namespace, even though the class-loader has
died.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
In article <·············@dont.t-systems.UCE.spam.no.com>,
Joerg Hoehle <············@dont.t-systems.UCE.spam.no.com> wrote:
> Pascal Costanza <········@web.de> writes:
> > BTWBTW, aren't the locales of T the kind of garbage-collected packages I
> > am looking for?
>
> It's long ago I read the T manual, but Oaklisp is a descendant of T
> and has locales. These are even objects. Conceptually, locales could
> exist solely as compile-time (or so) objects, like environment for the
> process of macroexpansion, or lexical environments.
In the book about T by Stephen Slade, it sounds like they also exist at
runtime. Hmph...
> Locales don't have names so they have no uniqueness restriction like
> packages. There's no FIND-LOCALE since there's no global list. For
> your purpose, they behave like Emacs- and older Lisp's obarrays, which
> the reader uses.
I don't know about obarrays. Thanks for this hint.
> However, since in a JVM, you can have equal package names designating
> different classes, CL packages are not a good way to represent these.
> You don't need package-names defined by uninterned symbols (which I
> believe is a misconception of yours anyway), you need either something
> else as packages, or a
> class-loader/namespace * java-package-designator -> unique-string-
> for use as CL package-name.
This is what I currently have (not much yet):
(defclass system-class-loader ()
((pkg :reader class-loader-package
:initform (make-package (gensym "GINA-") :use nil))))
(defmethod terminate ((instance system-class-loader))
(delete-package (class-loader-package instance)))
#+mcl
(defmethod initialize-instance :after ((instance system-class-loader)
&rest initargs &key
&allow-other-keys)
(declare (ignore initargs))
(terminate-when-unreachable instance))
#-mcl
(cerror
"Do without garbage collection of Gina packages."
"Gina packages are not garbage collected in this Common Lisp
implementation.")
So what I am doing is that I use a separate package for each class
loader. The Java classes as such are completely qualified, so the class
Object from the Java package java.lang.* gets the name java.lang.Object
(or currently, in my implementation, java-lang-object, to make things
look more lispish). This is the most straightforward thing to do,
because Java classes are also always completely qualified in class files.
(A conclusion from the discussion in this thread would be that the
gensym in the call to make-package abve doesn't make a lot of sense. I
guess I need to use my own scheme to create unique names for Gina
packages.)
The advantage of this approach seems to me that I can freely move from
class loader to class loader via Common Lisp's package system. (For
example, in order to change definitions, apply method combinations, and
so on... ;)
For those interested in more details: Java needs this kind of class
loader architecture in order to have different versions of the same
classes at the same time (for example). Java's packages alone are too
limited for that purpose. Class loaders in Java are garbage collected,
but they have got that right only in JDK 1.2.1 or 1.2.2. See http://citeseer.nj.nec.com/liang98dynamic.html for an excellent description of the class loader concept.
(BTW, this is not an endorsement of Java. ;)
> However, since there's a global list of packages, you cannot expect
> them to die without help. But you can use your favourite
> implementation of Lisp finalizers:
Yes, see above.
> But that has other problems, since methods from one of these may still
> be hold somewhere else, and they might still expect to get the package
> for "javax.sql" in their namespace, even though the class-loader has
> died.
I didn't completely understand this last bit. In a JVM, you can't refer
to a class in any package without going through a class loader object.
So that situation can't arise.
Thanks a lot for your comments,
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Pascal Costanza <········@web.de> writes:
> In article <·············@dont.t-systems.UCE.spam.no.com>,
> Joerg Hoehle <············@dont.t-systems.UCE.spam.no.com> wrote:
>
> > Pascal Costanza <········@web.de> writes:
> > > BTWBTW, aren't the locales of T the kind of garbage-collected packages I
> > > am looking for?
> >
> > It's long ago I read the T manual, but Oaklisp is a descendant of T
> > and has locales. These are even objects. Conceptually, locales could
> > exist solely as compile-time (or so) objects, like environment for the
> > process of macroexpansion, or lexical environments.
>
> In the book about T by Stephen Slade, it sounds like they also exist at
> runtime. Hmph...
I'm hesitant to take this on, since I was only using T during its initial
design, and it's now been about 20 years, but I don't suppose the history
of this is adequately documented anywhere, and locales were originally my
idea, so let me explain how both of these concepts could seem right, at
least in the early versions of T. Whether or not this is a description of
how T ended up is not something I know.
I wanted to have a 'global' notion and Jonathan Rees, who I was working
with, didn't like 'global' because it had inevitable name clashes and was
semantically a mess if everyone shared it. So I bargained down to what
we called 'locally global'. That is, it used the metaphor of a global
namespace kind of like CL has, but it wasn't really global in the sense of
shared. I thought the notion of not having to write parens around everything
was a useful programming device and so I wanted at least that much sense of
free variables. But I didn't really need the sense of free variables where
everyone in the universe shared the same space and could mindlessly bash
each others' code.
Some locales were quite ephemeral. e.g., we consed a new locale for every
call to #. so that you could do elaborate things like define helper functions
in them, as in
#.(begin (define (twice x) (* x 2))
(twice 3))
except we discarded the locale afterward (to discourage any important
functions from getting defined there, which we considered stylistically
bad), so that once 6 was returned, the whole locale was discarded
(and, indeed, gc'd).
So how long the life of a locale is was really dependent on how you
used it. For example, other locales were held onto because they were
intended to be saved and used later by reference to a name, vaguely
like IN-PACKAGE. You were always given a locale to start with that
had a set of bindings that were thought to be appropriate for
bootstrapping you into whatever you needed, more or less like in a
file system how you know you'll begin with a home directory (~foo) and
can build downward (~foo/x/y) from there. In a file system, you'd
also be able to do absolute references to find the system things in
your environment (/usr/bin/bash), but in T you were instead
pre-initialized with a set of bindings for things you'd need (~foo/+,
~foo/list, etc. rather than /usr/bin/+, /usr/bin/list, etc.), and then
you could rearrange them around to your heart's content to get things
how you liked, since their name didn't matter, only their function.
[We actually had talk of a notation like #>foo>bar>baz, which would
give a Multics-like syntax to the lookup, but it would have been
different than Multics-style lookup in the sense that it wasn't absolute
reference from a known root, but rather
(get-name 'baz (get-name 'bar (get-name 'foo (initial-locale))))
where (initial-locale) didn't access global state, but was something
that was initialized in your initial environment to be a constant
function that returned the locale that was your initial environment.
We didnt work out all of the details of this, and I don't know if this
was pursued. But we were quite interested in the notion of exploring
relative file systems as opposed to absolute ones.]
I think we talked about the idea of sealing up a locale (in the way that
Dylan later did sealing) for production 'shrink wrapped' delivering of
a product that no longer needed the stretchy generality of a locale, but
I don't know if that ever got implemented. If it did, this would be the
part that seems like it could go away at compile time, leaving just a
mapping table of names to values that could be loaded by another module.
But locales were intended also to be like packages--places you could live
and do interactive work later on, extending them further and having new
free variable references get created there rather than some outer place.
(I also vaguely recall some sort of inheritance structure and the notion
of having locale's have a bit saying whether to create new free references
in the locale, or whether to seek the parent to do that creation. It's
been too long for me to remember the detail.)
The metaphor I used for talking about 'semantic attachment' as I called it,
was that a program has a bunch of "hooks" for each of the unresolved names,
and you drag them through some muck (an environment) that has names
available. And the hooks connect with the names that are compatible, but
maybe not all hooks get resolved. Each new environment you encounter is
a chance to catch more names, like going fishing. Eventually the exprssion
is entirely resolved (and has been 'grokked', was the term I used).
So (lambda (x) (cons x foo)) would get dragged through the compiler's locale
and would end up with [i'll use uppercase to show a name that has caught
a meaning and is no longer a hook] (LAMBDA (X) (list X foo)). And you
might at runtime find a locale that had a search list first through a shared
locale (with no creation option set, so behaving like a 'used package')
to grab a meaning for LIST and end up with (LAMBDA (X) (LIST X foo)) and
finally the load environment would have to create FOO because it was not
found and you'd end up with (LAMBDA (X) (LIST X FOO)). Obviously, it wasn't
still a list. But the point is that each of these names had to have some
meaning associated with it, and you had to find these names at different
times and process them. So each locale provided a chance to do that.
I don't know whether the search list part was ever implemented, or whether
when it was it was in quite that form.
So this might all have been a description of something no one has ever seen
deployed. :)
I did the initial language design for T, but I was only on the project
for 3 months, so it probably changed a lot after I was there. The
project began with me wanting to create a language, but not a
compiler, and with Jonathan Rees wanting to create a compiler, but not
a language. We had weekly meetings where we reconsidered all kinds of
presuppositions we had about Lisp and Scheme and tried to decide which
to keep and which to toss. (I think I still have most of the
documents that fed into these.) Norm Adams was also there at that
time, but was new to Lisp at that point, and didn't come 'into his
own' until later. Norm was a sharp guy, but was still mostly in
learning mode that summer while I was there. Jonathan and I just
played with ideas and prototypes all summer and tried to get something
fun going. Then I had to get back to MIT and left it to him and Norm
and later others to continue with.
> > Locales don't have names so they have no uniqueness restriction like
> > packages. There's no FIND-LOCALE since there's no global list. For
> > your purpose, they behave like Emacs- and older Lisp's obarrays, which
> > the reader uses.
>
> I don't know about obarrays. Thanks for this hint.
Locales aren't about symbols, btw, but about bindings. So it's not a
package issue, and in that sense not similar to obarrays. But in the
sense of being unnamed tables, I suppose you could still build a vague
analogy.
(Remember that in Scheme you only have one package and so all information
is packaged lexically. Unlike in CL, you don't have X-WINDOWS:OPEN and
BOOK:OPEN and CL:OPEN (for files), you instead start with a bare
environemnt that maybe has just OPEN (for files) and then you access
some environment containing X-windows and a hypothetical BOOK module
and you say "I think in my locale I'll map X-OPEN to X-Windows' OPEN
function and BOOK-OPEN to my BOOK package's OPEN function. And, gee,
I think I'll eliminate the mapping for OPEN, replacing it with a
FILE-OPEN mapping, so I don't get myself confused about what the
unqualified OPEN is doing.")
This is very different than Maclisp obarrays, which permitted you to have
lookalike symbols FOO and FOO where one was in one obarray and one was
in another but they were not EQ.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| (Remember that in Scheme you only have one package and so all information
| is packaged lexically. Unlike in CL, you don't have X-WINDOWS:OPEN and
| BOOK:OPEN and CL:OPEN (for files), you instead start with a bare
| environemnt that maybe has just OPEN (for files) and then you access
| some environment containing X-windows and a hypothetical BOOK module
| and you say "I think in my locale I'll map X-OPEN to X-Windows' OPEN
| function and BOOK-OPEN to my BOOK package's OPEN function. And, gee,
| I think I'll eliminate the mapping for OPEN, replacing it with a
| FILE-OPEN mapping, so I don't get myself confused about what the
| unqualified OPEN is doing.")
+---------------
The PLT Scheme guys addressed a lot of this with their notion of namespaces
<URL:http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-8.html> and
then the whole units/signatures system and the module system which replaced
it <URL:http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-5.html>.
(Think of a DEFPACKAGE that contains almost-top-level definitions of
functions and variables, plus the usual imports & exports stuff.)
But none of that is standardized, of course...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza <········@web.de> writes:
> Do I have a correct understanding of these matters? For example, do
> existing CL implementations automatically call delete-package on a
> package that is identified by a gensym, as soon as the gensym is
> gc'ed?
I don't think you can portably test whether they do or not, so does
it matter?
--
a newbie: Why doesn't Lisp have pass by reference?
Erik Naggum: Because C++ doesn't have multiple return values.
(from a conversation in comp.lang.lisp)
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> Hi everybody,
>
> Here is a question of understanding: There are several constructs in
> Common Lisp that define named entities (not an established term, just
> made up on the spot). I am thinking about classes that you need to name
> in the defclass macro, or packages that you need to name when you do a
> defpackage or make-package.
Or how about functions named with DEFUN.
> So names that have been defined once need to retain the definitions
> associated with their symbols until they are explicitly uninterned, or
Uninterning a symbol is not the same as destroying it; it is just
removed from a package. It's similar to REMHASH-ing some object from a
hash table.
(defvar x 'foo)
(defvar foo "FOO's value")
(unintern 'foo)
x -> #:FOO
(eq x 'foo) -> NIL
(symbol-value x) -> "FOO's value"
The symbol hasn't gone away, it's just now a homeless wanderer. It has
retained its value binding, even. In the EQ expression, a brand new
FOO was interned in its place, so it's not EQ to the one that was
booted out of the package.
> the respective definitions are explicitly made unbound. Even if at times
> the names are not referenced in an image, they need to retain their
> definitions because those names can be read again some time in the
> future.
If a symbol is not interned in a package, the only way to refer to
that symbol in the future is through a retained pointer. This is what
the variable X does above to the symbol FOO. Once we overwrite X:
(setf x nil)
we have lost that symbol forever. No other references to the symbol
remain, and so it's now a GC candidate. When it is GC'd, the value
binding will disappear along with it. If that binding is the last
remaining reference to the string "FOO's value", that string is
garbage too.
> However, the uniqueness of gensyms is not captured by their names. If
Note that the uniqueness of interned symbols is also not captured by
their names. FOO::X and BAR::X both have the name "X". But they are in
different packages.
> you happen to type the name again of an already existing gensym, you
> still get a new symbol.
That is really just a reader behavior. It sees the notation #: so it
reads the name, and calls gensym. Whereas if it sees an unqualified
name, it uses intern instead which does the package lookup.
> Consequentially, when I use a gensym as the name
> of such an entity, can I rely on garbage collection to take care of
> associated definitions?
Not in general, only if that symbol is the only reference to those
definitions.
> My understanding is that, as soon as the gensym
> is gc'ed after I lose my references to it, the runtime system should
> delete the associated definitions.
No, because the entities named by these defintions can have references
to them other than through the name. For example a named function may
be captured because the (FUNCTION ...) operator was used somewhere, or
SYMBOL-FUNCTION was called to retrieve the function and stash it
somewhere.
But if no such stashing was done, then you are right; the associated
object can be collected too, e.g.:
(defun never-stashed ())
(unintern 'never-stashed)
There is no way to reach that function now; reading the expression
(symbol-function 'never-stashed) will cause a new symbol to be
interned which knows nothing about the old NEVER-STASHED.
> Do I have a correct understanding of these matters? For example, do
> existing CL implementations automatically call delete-package on a
> package that is identified by a gensym, as soon as the gensym is gc'ed?
The name of a package is a string, not a symbol. Symbols are allowed
in various package-related functions as a convenience, but it's their
name that is ultimately used. So if you use
(in-package :foo)
it's the same as
(in-package "FOO")
except that the former also interns the symbol FOO in the keyword
package when it is read, whereas the latter does no such
``pollution''. Some hackers use printed gensyms even:
(defpackage #:foo ...)
This is just a way of saying: I'm too lazy to hold down Shift or use
Caps Lock, or I don't feel like SHOUTING in my source code today. ;)
So we can transform this to the question: should the package named
"FOO" be deleted when the string "FOO" is garbage collected? That is
an absurd situation, because a package contains a backreference to its
name. So long as the package exists, you can call PACKAGE-NAME on it
to retrieve the name. So it is the lifetime of the name that depends
on the lifetime of the package, not the other way around.
In article <····························@posting.google.com>,
···@ashi.footprints.net (Kaz Kylheku) wrote:
> So we can transform this to the question: should the package named
> "FOO" be deleted when the string "FOO" is garbage collected? That is
> an absurd situation, because a package contains a backreference to its
> name. So long as the package exists, you can call PACKAGE-NAME on it
> to retrieve the name. So it is the lifetime of the name that depends
> on the lifetime of the package, not the other way around.
Yes, I have missed this bit in my OP. Thanks for your comments, they
were definitely much clearer than my somewhat vague wordings.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
From: Joe Marshall
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <fzp7fsze.fsf@ccs.neu.edu>
···@ashi.footprints.net (Kaz Kylheku) writes:
> Some hackers use printed gensyms even:
>
> (defpackage #:foo ...)
>
> This is just a way of saying: I'm too lazy to hold down Shift or use
> Caps Lock, or I don't feel like SHOUTING in my source code today. ;)
Of course these hackers seem to have forgotten that both : and # are
shifted characters.
Joe Marshall <···@ccs.neu.edu> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > Some hackers use printed gensyms even:
> >
> > (defpackage #:foo ...)
> >
> > This is just a way of saying: I'm too lazy to hold down Shift or use
> > Caps Lock, or I don't feel like SHOUTING in my source code today. ;)
>
> Of course these hackers seem to have forgotten that both : and # are
> shifted characters.
[ ]
The Lisp Machine had a giant [ : ] key (i.e., worked shifted
[ ] [ ~ ] [ ]
and unshifted) up in the left corner where [ ] and/or [ ESC ] typically
[ ` ] [ ]
are on normal keyboards. For that matter, the LispM also had unshifted
parens. And for all you hear people grump about parens, you never hear
the reason being that they're shifted... I guess because braces are, too.
I also find it weird that people who complain that FOO is shouting and foo
is not are still thrilled when they get colorized interfaces. I find _that_
to be much worse shouting than uppercase ever could be. It suggests to me
that the 'shouting' argument is made up after-the-fact because it plays well
in debates, and is not the real underlying reason for most people's version.
I'm not saying there are no reasons to prefer lowercase--I think there
are good reasons on both sides of the complex debate. One could rightly
discuss the issue of pressing chorded shift keys, for example.
But I never hear people complaining that parts of Java 'shout'.
I think that's because it isn't received viscerally as a shout, but
rather any discussion of shouting is added after-the-fact in some
discussions and not in others.
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey31y0rzc2f.fsf@cley.com>
* Joe Marshall wrote:
> Of course these hackers seem to have forgotten that both : and # are
> shifted characters.
Which is fine, since the reason for doing this is often to deal with a
certain well-known Lisp system which has a mutant
everything-in-lower-case mode.
--tim
From: Tim Bradshaw
Subject: Re: named entities that are gc'ed
Date:
Message-ID: <ey3isu3wecy.fsf@cley.com>
* I wrote:
* Joe Marshall wrote:
> Which is fine, since the reason for doing this is often to deal with a
> certain well-known Lisp system which has a mutant
> everything-in-lower-case mode.
Duane Rettig rightly picked me up for this unfortunate wording: I
didn't mean `mutant' in any kind of sense other than `variant'.
In particular I think that what I meant was: if you want to deal with
Lisps that might have variant case modes, then you need to use symbols
and not strings when you are talking about symbol names, if you want
your code to be robust, and if you don't want a lot of spurious
internery going on you need to use gensyms. So that's what I do for
package definitions &c.
--tim
···@ashi.footprints.net (Kaz Kylheku) writes:
> (defpackage #:foo ...)
> This is just a way of saying: I'm too lazy to hold down Shift or use
> Caps Lock, or I don't feel like SHOUTING in my source code today. ;)
Speaking of package name, would something like
(defpackage "J. Random Hacker's foo-package" ...)
be considered Very Bad Style Indeed?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/