Has anyone seen the page:
http://www.lib.uchicago.edu/keith/crisis/langs/Common-Lisp.html
A quote from the page:
> Modules 200 50
> I consider the package system to be severely broken.
I wonder what he thinks is broken about it?
but before you get upset, take a look at his history
http://www.lib.uchicago.edu/keith/crisis/history.html
he has some pretty funny comments about some languages...
Jimka wrote:
> Has anyone seen the page:
> http://www.lib.uchicago.edu/keith/crisis/langs/Common-Lisp.html
> A quote from the page:
>
>>Modules 200 50
>> I consider the package system to be severely broken.
>
> I wonder what he thinks is broken about it?
Several people think that the Common Lisp package system is broken. It
seems to me that this is mostly because Common Lisp packages are
foremostly a read-time concept. (You can have and use packages at
runtime, but the typical use is at read time, that is even before
compile time.)
For example, one problem that beginners typically have is that the
following doesn't do what they expect:
(let ((*package* (find-package "MY-PACKAGE")))
(print 'some-symbol))
The expectation here is that 'some-symbol will be interned in
'my-package. However, at the time this program fragment is run, the
interning of 'some-symbol is already completed before the *package*
variable is rebound.
The alternative would be to use a module system - here, I use the term
"module" in the sense that a module can be a runtime concept. This can,
in a sense, be understood as a generalization of closures. For example,
the typical way to modularize code in Scheme is as follows:
(define push (lambda (object) (error "Not defined yet.")))
(define pop (lambda () (error "Not defined yet.")))
(let ((stack '())
(define internal-push (lambda (object)
(set! stack (cons object stack))))
(define internal-pop (lambda ()
(let ((object (car stack)))
(set! stack (cdr stack))
object)))
(set! push internal-push)
(set! pop internal-pop))
Here, the let form creates a "module" that exports push and pop, but
stack is not imported, and so it is internal to that "module".
If I understand correctly, the module systems typically proposed for
Scheme all start from this basic idea and try to implement all kinds of
features on top (like lookup of bindings, parameterized modules, etc.).
You can find a recent discussion about Common Lisp packages at the
ll-discuss mailing list archive. See
https://lists.csail.mit.edu/pipermail/ll-discuss/2005-August/thread.html
- the relevant subthreads are "Pilot Error" and "Packages & Modules".
http://www.flownet.com/gat/locales.pdf is also interesting, as are the
papers listed at http://library.readscheme.org/page5.html
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> You can find a recent discussion about Common Lisp packages at the
> ll-discuss mailing list archive. See
> https://lists.csail.mit.edu/pipermail/ll-discuss/2005-August/thread.html
> - the relevant subthreads are "Pilot Error" and "Packages & Modules".
I have forgotten to say that one of the original designers of a
predecessor of Common Lisp packages has participated in that thread.
BTW, I think that the Common Lisp package system is among the best
things since sliced bread...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Several people think that the Common Lisp package system is broken. It
> seems to me that this is mostly because Common Lisp packages are
> foremostly a read-time concept. (You can have and use packages at
> runtime, but the typical use is at read time, that is even before
> compile time.)
One of the consequences of this, which can be a problem, is that all the
ways that a symbol can be used travel together. If a symbol names both
a function and a class slot, you can't export just one of these. So you
can't prevent someone from using (slot-value ... 'slot-name) instead of
calling the SLOT-NAME generic function.
This tends not to be a serious problem because CL is leniant about
allowing you to get around package boundaries. In most languages with
module systems, non-exported names are totally inaccessible outside the
module -- it's part of their information hiding goal. But in CL you can
simply use :: to access anything. So no one expects packages to provide
hard protection, and the fact that someone can access a slot name when
you only intended for them to access the function doesn't open you up to
anything they couldn't do anyway if they wanted. Also, there's nothing
forcing you to use the same name for both items.
So the package system gives programmers enough rope to hang themselves,
but we expect the programmers to know better than this.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> In article <···············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>Several people think that the Common Lisp package system is broken. It
>>seems to me that this is mostly because Common Lisp packages are
>>foremostly a read-time concept. (You can have and use packages at
>>runtime, but the typical use is at read time, that is even before
>>compile time.)
>
> One of the consequences of this, which can be a problem, is that all the
> ways that a symbol can be used travel together. If a symbol names both
> a function and a class slot, you can't export just one of these. So you
> can't prevent someone from using (slot-value ... 'slot-name) instead of
> calling the SLOT-NAME generic function.
Hm, what about just giving the two concepts different names?
> This tends not to be a serious problem because CL is leniant about
> allowing you to get around package boundaries. In most languages with
> module systems, non-exported names are totally inaccessible outside the
> module -- it's part of their information hiding goal. But in CL you can
> simply use :: to access anything. So no one expects packages to provide
> hard protection, and the fact that someone can access a slot name when
> you only intended for them to access the function doesn't open you up to
> anything they couldn't do anyway if they wanted. Also, there's nothing
> forcing you to use the same name for both items.
>
> So the package system gives programmers enough rope to hang themselves,
> but we expect the programmers to know better than this.
Right.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Barry Margolin wrote:
>
> > In article <···············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Several people think that the Common Lisp package system is
> >> broken. It seems to me that this is mostly because Common Lisp
> >> packages are foremostly a read-time concept. (You can have and use
> >> packages at runtime, but the typical use is at read time, that is
> >> even before compile time.)
> > One of the consequences of this, which can be a problem, is that all
> > the ways that a symbol can be used travel together. If a symbol
> > names both a function and a class slot, you can't export just one of
> > these. So you can't prevent someone from using (slot-value
> > ... 'slot-name) instead of calling the SLOT-NAME generic function.
>
> Hm, what about just giving the two concepts different names?
Who says they're different concepts? They're probably the same
concept: both refer to the aspect of the object that it names. It's
easy enough to work around, e.g. by naming the slot %FOO instead of
FOO. The package system isn't a module system, but with workarounds
like the above, it's close enough that (obviously) we get on just fine
without one.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'