Nested packages are one feature which might improve CL.
i.e.
P:F ; symbol F in package P
NS:P2:F ; symbol F in package NS:P
NS:P3:F
this would simplify grouped actions such as
(use-package :NS)
P2:F ; don't need to specify the outer scope
P3:F
or the aliasing of deeply-named packages
e.g.
NS1:NS2:P1:F
NS1:NS2:P2:F
(make-nickname :NS1:NS2 :NS3)
NS3:P1:F ; refer to NS1:NS2:P1:f
Some lispers emulate this via '.' in the package name, but that's not
the same. Its a convention, not a language construct.
Anyway, if anyone ever takes a stab at adding this to Lisp, be careful
when defining the rules for name resolution. C++ resolves names
starting from the current scope, searching parent scopes until the
symbol is found. This is generally nice (it reduces the effort
associated with creating new packages) but can be confusing. Here's a
short C++ puzzle.
#| Begin C++
#include <iostream>
using std::cout;
using std::endl;
struct SA
{
void f() { cout << "::SA" << endl; }
};
namespace NS
{
struct SB { SA a; };
struct SA
{
void f() { cout << "::NS::SA" << endl; }
};
struct SC { SA a; };
}
int main(int argc, char **argv)
{
NS::SB sb;
sb.a.f();
NS::SC sc;
sc.a.f();
return 0;
}
|#
What's this print out?
Would it surprise you to find that the equivalent Java code gives a
different answer?
C++ cares about both scoping and declaration/instantiation order.
Java's rules don't. The C++ rules would wreak havoc in Lisp.
Just some thoughts.
- Daniel
D Herring wrote:
> Some lispers emulate this via '.' in the package name, but that's not
> the same. Its a convention, not a language construct.
>
Note that '.' for hierarchical package naming already has additional
implementation support in CMUCL and Allegro and probably some other
lisps too though, via implementation-defined extensions:
http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc20
- it's already a little bit more than a naming convention, since some
relative package name forms are supported.
FWIW, I think I prefer '.' to ':' for hierarchical package naming
schemes, using ':' for separating package name from symbol name, as the
hierarchy is basically internal to the package textual names.
(one could imagine the resolver instead recursively looking for package
objects somehow Lisp-N-bound to symbols in packages, where multiple :
might be more appropriate, but bleurgh to that...)
David Golden wrote:
> D Herring wrote:
>
>> Some lispers emulate this via '.' in the package name, but that's not
>> the same. Its a convention, not a language construct.
>
> Note that '.' for hierarchical package naming already has additional
> implementation support in CMUCL and Allegro and probably some other
> lisps too though, via implementation-defined extensions:
>
> http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc20
Thanks for the link -- this should be easy to add to SBCL.
- Daniel
On Aug 15, 3:38 am, D Herring <········@at.tentpost.dot.com> wrote:
> Some lispers emulate this via '.' in the package name, but that's not
> the same. Its a convention, not a language construct.
Relative package names, per-package package nicknames and conduit
packages all have implementations which are mostly-portable already,
and are a lot more than a naming convention.
--tim
Tim Bradshaw wrote:
> On Aug 15, 3:38 am, D Herring <········@at.tentpost.dot.com> wrote:
>
>> Some lispers emulate this via '.' in the package name, but that's not
>> the same. Its a convention, not a language construct.
>
> Relative package names, per-package package nicknames and conduit
> packages all have implementations which are mostly-portable already,
> and are a lot more than a naming convention.
Hmm... A guy named Tim wrote http://www.tfeb.org/lisp/hax.html
I'll have to read up on this.
Thanks,
Daniel
In article
<····································@i76g2000hsf.googlegroups.com>,
Tim Bradshaw <··········@tfeb.org> wrote:
> On Aug 15, 3:38�am, D Herring <········@at.tentpost.dot.com> wrote:
>
> > Some lispers emulate this via '.' in the package name, but that's not
> > the same. �Its a convention, not a language construct.
>
> Relative package names, per-package package nicknames and conduit
> packages all have implementations which are mostly-portable already,
> and are a lot more than a naming convention.
>
> --tim
Lisp Machine Lisp had hierarchical packages. Does anyone remember if
they got much use?
--
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 <······@alum.mit.edu> writes:
> In article
> <····································@i76g2000hsf.googlegroups.com>,
> Tim Bradshaw <··········@tfeb.org> wrote:
>
> > On Aug 15, 3:38 am, D Herring <········@at.tentpost.dot.com> wrote:
> >
> > > Some lispers emulate this via '.' in the package name, but that's not
> > > the same. Its a convention, not a language construct.
> >
> > Relative package names, per-package package nicknames and conduit
> > packages all have implementations which are mostly-portable already,
> > and are a lot more than a naming convention.
> >
> > --tim
>
> Lisp Machine Lisp had hierarchical packages. Does anyone remember if
> they got much use?
I think there were some portability issues that were a barrier to some
otherwise good ideas. They may have been only in the LMITI
system--does anyone have copies of chinuals to compare to Genera doc?
Also, CL (in the pre-CLTL timeframe, not sure whose idea--maybe
Steele's) tried to grab the idea but changed it in the process so I
think it wasn't compatible. As I recall, there was in the CL proposal
some initial package called PACKAGE in which basic package names were
interned but you could intern other symbols in some somehow-nested way
that could also name packages. I don't know if it was ill-debugged or
just incompatible, but it disappeared before CLTL(84) came out. (It
may have fought with the notion of internal/external symbols, since in
the hierarchy there may have been a separate : vs :: choice at every
join. I think I joined that committee in 81 or 82, and it was already
present so I don't think I saw the discussion, and then it was gone
almost as soon as I saw it.)
Genera has syntax-local package names, which I designed and
implemented, generalizing a kludge that someone else had done as a
kind of special case. I created a notion of a first-class object
called a syntax, and within it was a "package universe" which was an
alist of aliases for certain packages that didn't like the global
arrangement of names. Within a syntax, those package names would
prevail over the global names. This allowed packages that had
different names for the same package to co-reside gracefully. (There
was a competition between ZL and CL over who got the package name
USER. The packages globally known as ZETALISP-USER and
COMMON-LISP-USER got the package names USER locally in the Zetalisp
and Common-Lisp syntaxes, respectively. Within the ANSI-Common-Lisp
syntax, the package names FUTURE-COMMON-LISP and
FUTURE-COMMON-LISP-USER were aliased to the respective packages
COMMON-LISP,CL and COMMON-LISP-USER,CL-USER. ... or some such
arrangement--I'm doing this from memory.) This mechanism, while local
to syntaxes, would have worked per-package, and would have been
another way of dealing with the issue: allow global package names
(e.g., COM.ACME.FOO) with local short names visible within a context.
The real trick of the Genera system was making sure that users were
not surprised by when one or another package universe was in play; it
was tricky to orchestrate so that it didn't cause people to think that
CL semantics was violated (even though it had to play some games at
the fringes). In a system designed around users knowing about it,
it's easier. But that involves incompatible change.
All in all, though, my recent work has suggested to me that the
problem is a red herring, and that short package names are not what's
needed. What's really needed is better import/export tools so that
people don't have to name packages so much. That can be written
portably and since I started using something that does that, I've had
far less problems with it. Except in the exceedingly rare case where
you need to use two symbols with the same name from different packages
in the same program, I usually find it easy to just import everything
you need and not make references to symbols to unqualified symbols. I
found I did a lot more explicit package references when I didn't have
good tools for import/export. I don't think what DEFPACKAGE has by
default is as useful as what's needed, but I've worked out some things
I like better and it's been working for me. (I'd like to publish it
for general use at some point, but I've not quite gotten to that for
various rasons. I apologize for the resulting vagueness, but I wanted
to at least inject the notion that these are intertwined concepts and
that the desire for a thing can potentially be a deficiency of
something else.)
On Aug 17, 11:51 am, Kent M Pitman <······@nhplace.com> wrote:
[[...]]
> All in all, though, my recent work has suggested to me that the
> problem is a red herring, and that short package names are not what's
> needed. What's really needed is better import/export tools so that
> people don't have to name packages so much. That can be written
> portably and since I started using something that does that, I've had
> far less problems with it. Except in the exceedingly rare case where
> you need to use two symbols with the same name from different packages
> in the same program, I usually find it easy to just import everything
> you need and not make references to symbols to unqualified symbols. I
> found I did a lot more explicit package references when I didn't have
> good tools for import/export. I don't think what DEFPACKAGE has by
> default is as useful as what's needed, but I've worked out some things
> I like better and it's been working for me. (I'd like to publish it
> for general use at some point, but I've not quite gotten to that for
> various rasons. I apologize for the resulting vagueness, but I wanted
> to at least inject the notion that these are intertwined concepts and
> that the desire for a thing can potentially be a deficiency of
> something else.)
Just now, I found this article, and thought it might be relevant:
http://www.foldr.org/~michaelw/log/programming/lisp/defpackage-form
though I personally have no opinion, and this is not too "itchy" that
it needs scratching for me.