[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help sought understanding shorthands wrt modules/packages
From: |
Richard Stallman |
Subject: |
Re: Help sought understanding shorthands wrt modules/packages |
Date: |
Tue, 08 Nov 2022 23:03:20 -0500 |
[[[ 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. ]]]
> > If you're talking about the :USE directive,
I implemented CL packages 40 years ago -- I don't remember the details.
There was a feature that let you specify, in one package FOO, "Let me
omit package prefixes when I refer to symbols from package BAR."
Then if BAR defines a symbol BAR:HACK, and you write HACK in package FOO
with no prefix, the package system would search for a symbol HACK, find
it in package BAR, and treat HACK as an alias for BAR:HACK.
Is that what :USE does? If so, it would seem that :USE is the bad design
I am talking about.
The general idea is a nice one, but it doesn't work in Lisp.
A Lisp symbol has a value, a function definition, a property list, and
an identity. Since CL packages handle this by interning one symbol in
multiple alists, it gangs together the symbol's slots with its
identity. If the function FOO:HACK means BAR:HACK, then the variable
FOO:HACK means BAR:HACK, and the propery list FOO:HACK means that of
BAR:HACK, and FOO:HACK as a property name means BAR:HACK.
Even examining the value of HACK with FOO selected is enough to do
intern that particular symbol HACK in FOO.
Making it even worse, once BAR:HACK is recorded as the meaning of HACK
in FOO's symbol table (obarray), there was no way to make it mean some
other symbol HACK.
Suppose that package FOO says to allow reference without explicit
prefix to symbols from packages ADDED and BAR. Suppose BAR has a
symbol HACK and ADDED does not have one. In FOO you the HACK, and it
becomes aliased to BAR:HACK.
Suppose you then define another symbol called ADDED:HACK. Now the
meaning of HACK in FOO has been changed. But it can't really be changed,
because the obarray for FOO already contains the HACK that is BAR:HACK.
This is a gross bug. We should not implement such a bug. No one ever
should.
We can make package systems that behave naturally and consistently.
But they can't be compatible with CL packages.
--
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: A short defense of shorthands.el (but CL packages are still better), (continued)
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/04
- Re: A short defense of shorthands.el (but CL packages are still better), Richard Stallman, 2022/11/07
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/07
- Re: A short defense of shorthands.el (but CL packages are still better), Richard Stallman, 2022/11/08
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/08
Re: Help sought understanding shorthands wrt modules/packages, Richard Stallman, 2022/11/04
Re: Help sought understanding shorthands wrt modules/packages,
Richard Stallman <=
Re: Help sought understanding shorthands wrt modules/packages, Yuri Khan, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, tomas, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Matt Armstrong, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Juanma Barranquero, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Gerd Möllmann, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Helmut Eller, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Matt Armstrong, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Richard Stallman, 2022/11/08
Re: Help sought understanding shorthands wrt modules/packages, Matt Armstrong, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Richard Stallman, 2022/11/02