Re: [External] : CL packages landed

Re: [External] : CL packages landed

[Payas Relekar]

Drew Adams <drew.adams@oracle.com> writes:

>> I've pushed the branch "pkg" which implements CL packages for Emacs.
>
> Bonne initiative !  Really appreciated, Gerd.
> ___
>
> Now we should figure out a good way to disambiguate
> the use of the word "package", for our docs etc.,
> to help users understand that this and the Emacs
> "package" system are completely different species.

Elixir has 'module' and I quite like it, but that might conflict with so
called 'dynamic modules' in Emacs land.

--

RE: [External] : CL packages landed

[Drew Adams]

> >> I've pushed the branch "pkg" which implements CL packages for Emacs.
> >
> > Bonne initiative !  Really appreciated, Gerd.
> > ___
> >
> > Now we should figure out a good way to disambiguate
> > the use of the word "package", for our docs etc.,
> > to help users understand that this and the Emacs
> > "package" system are completely different species.
> 
> Elixir has 'module' and I quite like it, but that might conflict with so
> called 'dynamic modules' in Emacs land.

Dunno whether you see that as a possibility for the
existing "package" system or as a possibility for
CL "packages".  Could be either.

CL packages are essentially _namespaces_ - something
less than what modules are sometimes asked to do.

(FWIW, I think it's too bad we chose "package" for a
library, but it is what it is.)  We could perhaps
choose "namespace" for what's really (or essentially?)
a CL package.

No to CL packages

[Richard Stallman]

[[[ 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. ]]]

CL packages are badly designed, and can't work well if implemented in
the natural way (at read time).  Please do not install anything like
that.

The symbol-renaming system, shorthands, is meant can be the basis of a
much better implementation of namespaces.  We just need to finish it.

What we have is a way for a file foo.el to specify renamings to apply
to its contents.

What is missing is a way to load file foo.ek with with specified
certain additional renamings, in addition whatever is specified in
foo.el itself.

With that, we will be able to implement packages that work reliably
and without ambiguities.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: No to CL packages

[Gerd Möllmann]

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. ]]]
>
> CL packages are badly designed, and can't work well if implemented in
> the natural way (at read time).

In your opinion.

A lot of people involved in Command Lisp standardizatoun and
implementation think they work well enough, and in my and other's
experience they do.

> The symbol-renaming system, shorthands, is meant can be the basis of a
> much better implementation of namespaces.  We just need to finish it.

I see no need to invent yet another package system.

> 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?

P.S.

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.

CMU has a page from which you can download the book in various formats:
        
  https://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html

Re: No to CL packages

[Richard Stallman]

[[[ 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.

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

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

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?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: No to CL packages

[Gerd Möllmann]

[-- 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 --]