Hello,
Is there an idiomatic way to :use, or otherwise import/refer to, a
package by a nickname defined in the using package? That is, in
pseudo-CL:
(defpackage ...
(:use :something
:else
(:really-long-package-name :my-nick)))
Alternatively some form of reader macro or similar, since I suspect it
is not possible to do the above, given the nature of symbols and their
interning in packages. Granted, when printed back out again it will be
less readable.
I am perpetually in limbo in choosing short-but-possibly-conflicting
package names vs long-but-guaranteed-to-be-unique package names.
If I choose the former, I feel that I am risking conflicting with
other people's package names (the likelyhood of two people using
e.g. "cl-irc" is not that low for example). In addition, it
discourages splitting your code into multiple packages
(cl-irc.something.other and cl-irc.something.else are no longer short)
- something I find useful because it allows separation into more
specific namespaces where one can be much more free in the naming of
public symbols.
If I choose longer names such as the Java style names suggested by
Practical Common Lisp (i.e., tld.domain.software.sub.package), I
*know* that no one will want to ever write that out in code. As a
result everyone is going to want to :use the package. This in turn
means that I am back to having to worry about global symbol naming
conflicts instead of being able to freely design my nomenclature
locally to my package. (Package nicknames do not really help because I
am still not pushing the choice of prefix onto the user of the
package.)
I realize that Common Lisp:ers have lived without doing what I propose
for a long time. Nevertheless, I cannot shake the constant and
perpetual feeling that I am under the gun with naming.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
Use unique short names. Just pick a unique name for your project
(e.g. there should only be one CL-IRC; the next one should be YACL-IRC
or IRCL or BuzzBot or whatever).
--
Robert Uhl <http://public.xdi.org/=ruhl>
That was possibly the only time in my entire career that somebody actually
noticed and cared to say that they were impressed by something I'd achieved.
These days, I could turn lead into gold, and I'd be whinged at because they
wanted platinum. --Peter Corlett
Apologies. I just wanted to post a follow-up with my proper E-Mail
address. It's been a while since I posted through gnus, and I failed
to realize I had not properly set up my identity. Apologies.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
From: Matthias Buelow
Subject: Re: Package nicknaming at :use time or reader time
Date:
Message-ID: <6e9c8oF618fhU1@mid.dfncis.de>
User Scode wrote:
> I am perpetually in limbo in choosing short-but-possibly-conflicting
> package names vs long-but-guaranteed-to-be-unique package names.
Use the short ones; long, Java-style namespaces are just bureaucratic
clutter with no real practical value (imho, of course).
Matthias Buelow <···@incubus.de> writes:
>> I am perpetually in limbo in choosing short-but-possibly-conflicting
>> package names vs long-but-guaranteed-to-be-unique package names.
>
> Use the short ones; long, Java-style namespaces are just bureaucratic
> clutter with no real practical value (imho, of course).
Opinion clearly varies. I just know that whenever I am writing code in
any language, be it Lisp, Ruby, Python, C++, Java, etc - I *always*
feel more comfortable when I have control over the namespace in which
my names will potentially conflict.
This is particularly the case with functional code, or generic
function OO code, because you do not have the implicit namespacing
that message passing implies in making method names local to their
class (and subclasses). As a result you end up having a much higher
number of total names that you need to avoid conflicts with.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
Matthias Buelow <···@incubus.de> writes:
> User Scode wrote:
>
>> I am perpetually in limbo in choosing short-but-possibly-conflicting
>> package names vs long-but-guaranteed-to-be-unique package names.
>
> Use the short ones; long, Java-style namespaces are just bureaucratic
> clutter with no real practical value (imho, of course).
Well if lisp detractors were right, if there was no lisp library, it
would be ok. But unfortunately there are a lot of lisp libraries, and
several of each category. You've got several XML libraries, several
HTML libraries, several CVS libraries, several RFC2822 libraries, etc,
etc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
P� Thu, 17 Jul 2008 18:55:05 +0200, skrev User Scode
<·····@hyperion.scode.org>:
> Hello,
>
> Is there an idiomatic way to :use, or otherwise import/refer to, a
> package by a nickname defined in the using package? That is, in
> pseudo-CL:
>
> (defpackage ...
> (:use :something
> :else
> (:really-long-package-name :my-nick)))
>
Well :nick allows you to use short package names without causing conflict.
If short names conflict one has :shadow and :shadow-import.
(setf (symbol-function 'new-name) 'package:old-name) gives a function a
new local name.
--------------
John Thingstad
"John Thingstad" <·······@online.no> writes:
> Well :nick allows you to use short package names without causing conflict.
> If short names conflict one has :shadow and :shadow-import.
Hmm. I cannot find :nick in the clhs page for defmacro. Am I missing
something, or did you mean :nicknames? If the latter, my problem there
was that the choice of nicks happens at package definition, rather
than package use.
Shadowing imports may help if one is lucky, but it still requires me
to choose one or the other - I can't access both without using the
fully qualified name, or a short name provided by the author of the
package.
> (setf (symbol-function 'new-name) 'package:old-name) gives a function
> a new local name.
This is true, but I am worried about it causing unintended
side-effects because it won't *be* the same symbol (for example,
suppose a package provides a macro that traverses a body of code
looking for calls to some particular function by checking symbol
equality, or by looking at other properties of the symbol).
In this regard I was hoping a read-time alias would provide the
desired semantics since the read data structure should be
indistinguishable from what you would have gotten had you typed out
the full name.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
P� Thu, 17 Jul 2008 19:37:11 +0200, skrev Peter Schuller
<··············@infidyne.com>:
> "John Thingstad" <·······@online.no> writes:
>
>> Well :nick allows you to use short package names without causing
>> conflict.
>> If short names conflict one has :shadow and :shadow-import.
>
> Hmm. I cannot find :nick in the clhs page for defmacro. Am I missing
> something, or did you mean :nicknames? If the latter, my problem there
> was that the choice of nicks happens at package definition, rather
> than package use.
>
> Shadowing imports may help if one is lucky, but it still requires me
> to choose one or the other - I can't access both without using the
> fully qualified name, or a short name provided by the author of the
> package.
>
>> (setf (symbol-function 'new-name) 'package:old-name) gives a function
>> a new local name.
>
> This is true, but I am worried about it causing unintended
> side-effects because it won't *be* the same symbol (for example,
> suppose a package provides a macro that traverses a body of code
> looking for calls to some particular function by checking symbol
> equality, or by looking at other properties of the symbol).
>
> In this regard I was hoping a read-time alias would provide the
> desired semantics since the read data structure should be
> indistinguishable from what you would have gotten had you typed out
> the full name.
>
From defpackage in hyperspec:
defpackage defined-package-name [[option]] => package
option::= (:nicknames nickname*)* |
(:documentation string) |
(:use package-name*)* |
(:shadow {symbol-name}*)* |
(:shadowing-import-from package-name {symbol-name}*)* |
(:import-from package-name {symbol-name}*)* |
(:export {symbol-name}*)* |
(:intern {symbol-name}*)* |
(:size integer)
--------------
John Thingstad
User Scode <·····@hyperion.scode.org> writes:
> Hello,
>
> Is there an idiomatic way to :use, or otherwise import/refer to, a
> package by a nickname defined in the using package? That is, in
> pseudo-CL:
>
> (defpackage ...
> (:use :something
> :else
> (:really-long-package-name :my-nick)))
>
> Alternatively some form of reader macro or similar, since I suspect it
> is not possible to do the above, given the nature of symbols and their
> interning in packages. Granted, when printed back out again it will be
> less readable.
>
> I am perpetually in limbo in choosing short-but-possibly-conflicting
> package names vs long-but-guaranteed-to-be-unique package names.
>
> If I choose the former, I feel that I am risking conflicting with
> other people's package names (the likelyhood of two people using
> e.g. "cl-irc" is not that low for example). In addition, it
> discourages splitting your code into multiple packages
> (cl-irc.something.other and cl-irc.something.else are no longer short)
> - something I find useful because it allows separation into more
> specific namespaces where one can be much more free in the naming of
> public symbols.
>
> If I choose longer names such as the Java style names suggested by
> Practical Common Lisp (i.e., tld.domain.software.sub.package), I
> *know* that no one will want to ever write that out in code. As a
> result everyone is going to want to :use the package. This in turn
> means that I am back to having to worry about global symbol naming
> conflicts instead of being able to freely design my nomenclature
> locally to my package. (Package nicknames do not really help because I
> am still not pushing the choice of prefix onto the user of the
> package.)
>
> I realize that Common Lisp:ers have lived without doing what I propose
> for a long time. Nevertheless, I cannot shake the constant and
> perpetual feeling that I am under the gun with naming.
Have a look at my DEFINE-PACKAGE macro:
http://darcs.informatimago.com/darcs/public/lisp/common-lisp/package.lisp
However, it's deprecated, it's not so good.
Nowadays I use defpackage/in-package in a standard way, and just add
to my source files a declaration to signal additionnal dependencies.
The nicknames I add them from the loader.lisp files (See
COM.INFORMATIMAGO.COMMON-LISP.PACKAGE:ADD-NICKNAME).
However, the problem is to define an _interface_, a common set of
symbols that the various libraries/packages will export, so that you
can choose one by adding it a short nickname that you will use from
dependent packages. Otherwise you will get different symbols exported
under the same nickname depending on which package you assigned the
nickname to.
I use nicknames only as interactive shortcuts, not in source files.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
> Have a look at my DEFINE-PACKAGE macro:
> http://darcs.informatimago.com/darcs/public/lisp/common-lisp/package.lisp
>
> However, it's deprecated, it's not so good.
Thanks! It's interesting nontheless to see what other people have
done. I am glad I am not *completely* alone in having felt the need.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
On Thu, 17 Jul 2008 18:55:05 +0200, Peter Schuller <··············@infidyne.com> said:
| ...
| I am perpetually in limbo in choosing short-but-possibly-conflicting
| package names vs long-but-guaranteed-to-be-unique package names.
If you want to _write_ short package qualifiers in your code for
other packages' symbols, use something along the lines of
(defun add-nicknames (package &rest new-nicknames)
"Add NEW-NICKNAMES to PACKAGE's existing nicknames."
(let ((name (package-name package))
(nicknames (package-nicknames package)))
(rename-package package name (append new-nicknames nicknames))))
and if you want the symbols from a package to have a short package
qualifier when they are _printed_, use something along the lines of
(defun set-new-name (package new-name)
"Set PACKAGE's name to NEW-NAME, making the existing name a nickname."
(let ((name (package-name package))
(nicknames (package-nicknames package)))
(rename-package package new-name (cons name nicknames))))
where the latter is for a (typical) implementation which uses
PACKAGE-NAME to obtain a package prefix when printing symbols.
ADD-NICKNAMES would be called after the corresponding package has
been defined; the call would typically have to be wrapped in
EVAl-WHEN for :COMPILE-TOPLEVEL and :EXECUTE. Strictly speaking, it
should be in a critical section, too, in the presence of
concurrency.
If you only call ADD-NICKNAMES for the sake of your own code, then
the short nicknames will be "private" to it.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
User Scode wrote:
> Hello,
>
> Is there an idiomatic way to :use, or otherwise import/refer to, a
> package by a nickname defined in the using package? That is, in
> pseudo-CL:
>
> (defpackage ...
> (:use :something
> :else
> (:really-long-package-name :my-nick)))
Have a look at my conduits stuff (http://www.tfeb.org/lisp/hax.html).
If you have the hierarchical packages thing as well (same page) then
the conduits version of DEFPACKAGE will allow you to do the following:
(defpackage :com.cley.cl-user
(:nicknames :com.cley.user)
(:use :org.tfeb.clc)
(:aliases
;; This means: if *PACKAGE* is COM.CLEY.CL-USER then CL:x means
;; ORG.TFEB.CLC:x. Note the order is (alias real-name).
(:cl :org.tfeb.clc)))
Note that hierarchical packages is not completely portable code since
it relies on being able to intervene in string->package lookup. I
forget which implementations it works (worked) in.
--tim
On Thu, 17 Jul 2008 18:55:05 +0200, User Scode <·····@hyperion.scode.org> said:
| Is there an idiomatic way to :use, or otherwise import/refer to, a
| package by a nickname defined in the using package?
By the way, to some extent this, or something like this, can be done
along the lines of the following example:
Let's say there are these third-party packages
(defpackage :au.transmutation.util (:export #:make-gold))
(defpackage :com.paracelsus.supergold (:export #:make-gold))
Then we do
(defpackage :basic-alchemy (:nicknames :ba))
(defpackage :extended-alchemy (:nicknames :xa))
to serve as "views" (what is the established term for this?) onto
the above packages, so that with
(import-export 'au.transmutation.util:make-gold :ba)
(import-export 'com.paracelsus.supergold:make-gold :xa)
we can use our short names BA:MAKE-GOLD and XA:MAKE-GOLD, e.g.
(eql 'au.transmutation.util:make-gold 'ba:make-gold) => t
(eql 'com.paracelsus.supergold:make-gold 'xa:make-gold) => t
where
(defun import-export (symbols &optional (package *package*))
(import symbols package)
(export symbols package))
probably needs a better name.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
On Jul 19, 5:33 am, Vassil Nikolov <···············@pobox.com> wrote:
> By the way, to some extent this, or something like this, can be done
> along the lines of the following example:
What you're talking about is pretty much conduit packages.
On Sat, 19 Jul 2008 05:34:54 -0700 (PDT), Tim Bradshaw <··········@tfeb.org> said:
| On Jul 19, 5:33�am, Vassil Nikolov <···············@pobox.com> wrote:
|| By the way, to some extent this, or something like this, can be done
|| � along the lines of the following example:
| What you're talking about is pretty much conduit packages.
Indeed. It's a shame I hadn't properly acquainted myself with them
before, even though you have mentioned them in comp.lang.lisp. By
the way, judging by the results of
<http://www.google.com/search?q=conduit+packages>, my ignorance is
unexcusable (and the name is well-chosen---compare to, say,
<http://www.google.com/search?q=conduit+modules>, to see how the
same word fares in a different combination).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.