Re: No to CL packages

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I see no need to invent yet another package system.
>
> We already have it, not quite finished.

That it's not yet finished is why I asked if there is a design that I
can read.  Because, from what is there, I can't figure out how it
replaces familiar package systems.

Familiar not in the sense of being familiar with CL, but more generally,
because what Python and many other languages do is at least similar, if
not inspired by what CL does.

>   > > With that, we will be able to implement packages that work reliably
>   > > and without ambiguities.
>
>   > You mention reliability and ambiguity.  What do you mean, in a concrete
>   > example?
>
> I can't write an example of Common Liso packages -- it was 40 years
> ago that I implemented them for the Lisp Machine.  But I recall what
> the unreliability was.  With CL packages, the reader searched a list
> of packages (specified by the current package) for a symbol with the
> name just read.  This means that the unexpected presence of a symbol
> with that name, in an early package in the list, could alter the
> meaning.
>
> If the list includes packages foo abd bar, and you write `my-hack'
> expecting the symbol to be found in bar, but unexpectedly foo contains
> a symbol named my-hack, you will get that one.

That's no longer a problem in CL, you'll get an error.  This is how it
looks in GNU/CLisp:

;; Create two packages names "FOO" and "BAR"
[1]> (defvar foo (make-package "FOO"))
[2]> (defvar bar (make-package "BAR"))

;; Make symbols "MY-HACK" in foo and bar and export them
[3]> (intern "MY-HACK" foo)
[4]> (intern "MY-HACK" bar)
[5]> (export 'foo::my-hack foo)
[6]> (export 'bar::my-hack bar)

;; Use (inherit from) package foo in the current package
;;   (common-lisp-user).
[7]> (use-package foo)
[8]> (find-symbol "MY-HACK")
MY-HACK ;
:INHERITED

;; Try to use bar
[9]> (use-package bar)

*** - (USE-PACKAGE (#<PACKAGE BAR>) #<PACKAGE COMMON-LISP-USER>): 1 name conflicts remain
      Which symbol with name "MY-HACK" should be accessible in #<PACKAGE COMMON-LISP-USER>?
The following restarts are available:
BAR            :R1      #<PACKAGE BAR>
COMMON-LISP-USER :R2    #<PACKAGE COMMON-LISP-USER>
ABORT          :R3      Abort main loop
Break 1 [14]> 

As a general principle in the CL package system, at most one symbol with
a given name is accessible in a package at any time.

>   > In case you're thinking in terms of the pre-CL package system that some
>   > Lisp machines had in the 80s, please read chapter 11 of "Common Lisp the
>   > Language 2nd edition" by Guy Steele.  CL's package system is not like
>   > the older one.
>
> I implemented packages according to the CL specifications.  Perhaps
> the specifications for packages have been changed since then.  I'm
> willing to look at that.

Thanks.

> Being hundreds of messages backlogged from the past 10 days, I'd
> rather not try to download the whole CL specs and search through them.
> Would you please email me that specific chapter?

Attaches as PDF.  If that's not working for you, I could also get the
LaTeX sources, if you want, but they are a bit hard to read.


[-- Attachment #2: CLtL2 chapter 11 --]
[-- Type: application/pdf, Size: 919945 bytes --]