I guess the owner / author of a package generally declares the
nicknames for the package. Usually the intention is to provide a
short name. Perhaps I'm missing something, but this seems to invite
collisions.
After thinking about it a little, I was wondering whether it makes
more sense for the _users_ of a package to declare nicknames.
Perhaps an example would help explain what I'm thinking about.
Let's say I'm going to use a code generator. I want to say:
(defpackage :rdm (:use :common-lisp)
(:nicknames (com.foobar.code-gen code-gen)))
Then within :rdm, I can write code like this:
(code-gen:frob '(some code gen input here))
instead of:
(com.foobar.code-gen:frob '(some code gen input here))
It should be OK to have another code generator loaded into the image.
But there is temptation for both of these packages to announce a
nickname of :code-gen, and then you have a collison.
-russ
On 2006-09-05 22:49:53 +0100, Russell McManus <·····@cl-user.org> said:
>
> After thinking about it a little, I was wondering whether it makes
> more sense for the _users_ of a package to declare nicknames.
Have a look at http://www.tfeb.org/lisp/hax.html, specifically the
sections on conduits and hierarchical packages. You can do:
(defpackage :org.tfeb.play
(:use :cl)
(:aliases :parser :com.cley.parser))
for instance
Tim Bradshaw <···@tfeb.org> writes:
> On 2006-09-05 22:49:53 +0100, Russell McManus <·····@cl-user.org> said:
>> After thinking about it a little, I was wondering whether it makes
>> more sense for the _users_ of a package to declare nicknames.
>
> Have a look at http://www.tfeb.org/lisp/hax.html, specifically the
> sections on conduits and hierarchical packages. You can do:
>
> (defpackage :org.tfeb.play
> (:use :cl)
> (:aliases :parser :com.cley.parser))
This is an interesting topic, and it led to go off and read Franz's
page about hierarchical packages.
http://www.franz.com/support/tech_corner/hierpackuser.lhtml
It does appear to me that hierarchical packages largely supersede the
need for nicknames. I haven't written any code using hierarchical
packages, but it would be cool to add this to one or more free cl's
and give it a try.
-russ
Russell McManus wrote:
> It does appear to me that hierarchical packages largely supersede the
> need for nicknames. I haven't written any code using hierarchical
> packages, but it would be cool to add this to one or more free cl's
> and give it a try.
No, they don't, any more than a heirarchical directory structure
supersedes the need for links (symbolic or hard) and for much the same
reason: I want to be able to define what IF:FOO means, and not have to
know what package it actually belongs to in some heirarchy. What is
needed is precisely, as the OP wanted, per-package nicknames.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> What is needed is precisely, as the OP wanted, per-package
> nicknames.
Well, I am the original poster. I was just observing that in the
actual use cases that sparked my question, hierarchical packages would
work just as well as per-package nicknames.
I agree that per-package nicknames can do other cool things that
hierarchical packages can not.
-russ
Tim Bradshaw wrote:
> Russell McManus wrote:
>
> > It does appear to me that hierarchical packages largely supersede the
> > need for nicknames. I haven't written any code using hierarchical
> > packages, but it would be cool to add this to one or more free cl's
> > and give it a try.
>
> No, they don't, any more than a heirarchical directory structure
> supersedes the need for links (symbolic or hard) and for much the same
> reason: I want to be able to define what IF:FOO means, and not have to
> know what package it actually belongs to in some heirarchy. What is
> needed is precisely, as the OP wanted, per-package nicknames
One cannot emphasize this enough. I think hierarchical packages are a
really bad idea.
It does not really solve the problem how to separate authoring and
usage of packages.
There is only one global hierarchy and if that isn't right in a
particular case you have to change
the hierarchy for all other users too. With per-package nicknames you
can locally organize
your packages in whatever way you want.
The hierarchical package naming-scheme is a pragmatical solution to get
unique package-names without central organisation - IMO that's the only
case in which a global package hierarchy is useful.
ciao,
Jochen
··@codeartist.org wrote:
>
> The hierarchical package naming-scheme is a pragmatical solution to get
> unique package-names without central organisation - IMO that's the only
> case in which a global package hierarchy is useful.
Precisely. It should be emphasized that it *is* useful. It's somewhat
disturbing to me that Lisp people *still* think it's reasonable to name
the package for their globally-available XML module XML or XML-UTILS or
something: like no one else will ever choose a package name which might
clash with that. DNS-based names are an extremely obvious solution,
and one which has an obvious precedent in what Java does. (From
another thread, this is a fine example of the extremely poor systems
engineering skills that programmers typically have.)
The bit of your article I elided above is also completely right - you
need to be able to construct a namespace *specific to a program* and
package-local nicknames do just that: for program a, XML:PARSE might
mean COM.CLEY.XML:PARSE, while for program b it might mean
COM.FRANZ.UTILS.XML:PARSE. In the same Lisp image, even. (Notably,
Java doesn't have that, at least not yet.)
--tim
Tim Bradshaw wrote:
> ··@codeartist.org wrote:
>
>> The hierarchical package naming-scheme is a pragmatical solution to get
>> unique package-names without central organisation - IMO that's the only
>> case in which a global package hierarchy is useful.
>
> Precisely. It should be emphasized that it *is* useful. It's somewhat
> disturbing to me that Lisp people *still* think it's reasonable to name
> the package for their globally-available XML module XML or XML-UTILS or
> something: like no one else will ever choose a package name which might
> clash with that. DNS-based names are an extremely obvious solution,
> and one which has an obvious precedent in what Java does. (From
> another thread, this is a fine example of the extremely poor systems
> engineering skills that programmers typically have.)
>
> The bit of your article I elided above is also completely right - you
> need to be able to construct a namespace *specific to a program* and
> package-local nicknames do just that: for program a, XML:PARSE might
> mean COM.CLEY.XML:PARSE, while for program b it might mean
> COM.FRANZ.UTILS.XML:PARSE. In the same Lisp image, even. (Notably,
> Java doesn't have that, at least not yet.)
Oberon had that, and it was really useful.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
>>>>> "Russell" == Russell McManus <·····@cl-user.org> writes:
Russell> It does appear to me that hierarchical packages largely supersede the
Russell> need for nicknames. I haven't written any code using hierarchical
Russell> packages, but it would be cool to add this to one or more free cl's
Russell> and give it a try.
CMUCL supports hierarchical package names.
Ray
Russell McManus <·····@cl-user.org> writes:
> I guess the owner / author of a package generally declares the
> nicknames for the package. Usually the intention is to provide a
> short name. Perhaps I'm missing something, but this seems to invite
> collisions.
Yes.
> After thinking about it a little, I was wondering whether it makes
> more sense for the _users_ of a package to declare nicknames.
Of course.
> Perhaps an example would help explain what I'm thinking about.
>
> Let's say I'm going to use a code generator. I want to say:
>
> (defpackage :rdm (:use :common-lisp)
> (:nicknames (com.foobar.code-gen code-gen)))
>
> Then within :rdm, I can write code like this:
>
> (code-gen:frob '(some code gen input here))
>
> instead of:
>
> (com.foobar.code-gen:frob '(some code gen input here))
>
> It should be OK to have another code generator loaded into the image.
> But there is temptation for both of these packages to announce a
> nickname of :code-gen, and then you have a collison.
The nicknames should be package-local.
When you :use a package, you should be able to nickname it.
I've got a DEFINE-PACKAGE macro that renames the used package to add
the wanted nickname, but we'd need a change to the standard to have
non-global nicknames. This is related to relative package names too.
Franz have an implementation of them.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Russell McManus schrieb:
> I guess the owner / author of a package generally declares the
> nicknames for the package. Usually the intention is to provide a
> short name. Perhaps I'm missing something, but this seems to invite
> collisions.
Yes the intention is to provide a shortname for a package,
particularily when you
explicitely specify the package like in (cl:format t ..) instead of
using USE-PACKAGE
to import the symbol in your package. You would certainly not want to
write (common-lisp:format ..)
everytime.
> After thinking about it a little, I was wondering whether it makes
> more sense for the _users_ of a package to declare nicknames.
This is how it seems to be - AFAICS. I personally always give my
packages long names by including one of my domains (org.codeartist,
de.codeartist or de.dataheaven). I sometimes specify nicknames for my
own packages but I do not use the nicknames in the source of the
package itself. Each IN-PACKAGE or other package
referencing/manipulation in my source-files will use the long package
name. So the nicknames can get removed or changed by my users using
RENAME-PACKAGE without breaking anything.
I think local package nicknames would be a great extension to the
current standard CL package semantics. Another thing I would have found
useful is an DEFPACKAGE option which allows to re-export external
symbols of particular used package. Fortunately one can write such an
add-on very easily in portable CL code. I use this to distinguish
between "interface packages" and "implementation packages". For each
module I first create a package which only exports symbols which should
later belong to the interface of the module. Instead of using this
interface packages with IN-PACKAGE I define other packages - the
implementation packages which just use the interface packages. If I
later want to make a package combining the interfaces in a single
package I just use all interface packages I need and re-export their
external symbols. My own DEFPACKAGE form has a :use-external switch
(which would be better named :use-and-export) which does the grunt
work.
ciao,
Jochen
····@codeartist.org wrote:
> I think local package nicknames would be a great extension to the
> current standard CL package semantics. Another thing I would have found
> useful is an DEFPACKAGE option which allows to re-export external
> symbols of particular used package. Fortunately one can write such an
> add-on very easily in portable CL code. I use this to distinguish
> between "interface packages" and "implementation packages". For each
> module I first create a package which only exports symbols which should
> later belong to the interface of the module. Instead of using this
> interface packages with IN-PACKAGE I define other packages - the
> implementation packages which just use the interface packages. If I
> later want to make a package combining the interfaces in a single
> package I just use all interface packages I need and re-export their
> external symbols. My own DEFPACKAGE form has a :use-external switch
> (which would be better named :use-and-export) which does the grunt
> work.
What you are talking about is conduit packages, I think:
(defpackage :org.tfeb.weld.low
(:use)
(:extends :org.tfeb.weld.low.portability-hacks)
(:extends :org.tfeb.weld.low.utilities)
...)
and even
(defpackage :org.tfeb.cl/conduits
(:use)
(:nicknames :org.tfeb.clc)
(:extends/excluding :cl #:export #:unexport #:defpackage
#:delete-package #:rename-package)
(:extends/excluding :org.tfeb.conduit-packages
#:recompute-conduits))
(indentation botched by google).
These can do per-package nicknames too (the latter being mildly
non-portable of course).
--tim