* Re: [External] : CL packages landed
@ 2022-10-21 15:24 Payas Relekar
2022-10-21 20:13 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Payas Relekar @ 2022-10-21 15:24 UTC (permalink / raw)
To: emacs-devel
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.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [External] : CL packages landed 2022-10-21 15:24 [External] : CL packages landed Payas Relekar @ 2022-10-21 20:13 ` Drew Adams 2022-10-23 19:11 ` No to CL packages Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2022-10-21 20:13 UTC (permalink / raw) To: Payas Relekar, emacs-devel@gnu.org > >> 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* No to CL packages 2022-10-21 20:13 ` Drew Adams @ 2022-10-23 19:11 ` Richard Stallman 2022-10-24 4:40 ` Gerd Möllmann 0 siblings, 1 reply; 6+ messages in thread From: Richard Stallman @ 2022-10-23 19:11 UTC (permalink / raw) To: Gerd Möllmann; +Cc: relekarpayas, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No to CL packages 2022-10-23 19:11 ` No to CL packages Richard Stallman @ 2022-10-24 4:40 ` Gerd Möllmann 2022-10-28 21:59 ` Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Gerd Möllmann @ 2022-10-24 4:40 UTC (permalink / raw) To: Richard Stallman; +Cc: relekarpayas, emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No to CL packages 2022-10-24 4:40 ` Gerd Möllmann @ 2022-10-28 21:59 ` Richard Stallman 2022-10-29 5:18 ` Gerd Möllmann 0 siblings, 1 reply; 6+ messages in thread From: Richard Stallman @ 2022-10-28 21:59 UTC (permalink / raw) To: Gerd Möllmann; +Cc: relekarpayas, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No to CL packages 2022-10-28 21:59 ` Richard Stallman @ 2022-10-29 5:18 ` Gerd Möllmann 0 siblings, 0 replies; 6+ messages in thread From: Gerd Möllmann @ 2022-10-29 5:18 UTC (permalink / raw) To: Richard Stallman; +Cc: relekarpayas, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-10-29 5:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-21 15:24 [External] : CL packages landed Payas Relekar 2022-10-21 20:13 ` Drew Adams 2022-10-23 19:11 ` No to CL packages Richard Stallman 2022-10-24 4:40 ` Gerd Möllmann 2022-10-28 21:59 ` Richard Stallman 2022-10-29 5:18 ` Gerd Möllmann
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.