Hello!
I'm trying to decide on the way of using packages to organize my code.
In various other projects, I've noticed the tendency of putting majority
of code/functionality into a single package. However, I'd prefer to
have a bit more namespace separation between various
modules/functionality, for reasons such as easier name conflict
avoidance, more explicit information on what is and what's not an
interface to the module, etc.
Let me just show an example of where I've been in my quest for the right
way to use packages. In one of the schemes that I devised, I thought of
using something like this (at the beginning of a file, probably):
(locally-use-package (:storage :nickname :st)
(:accounting :nickname :acc))
and then being able to write, for example, (st:store db key value),
(st:retrieve db key) within that file. (Note that it's different to
nicknames in defpackage.) I didn't try to implement this. I figured it
might be wiser to learn a bit more before I start telling
Lispers I've solved their problem. ;-)
So, what I am looking for is an advice on using packages to organize
code and namespaces in CL. Do you just use name-prefixing, e.g.
storage-store? Do you use hierarchical packages? Do you have a single
policy at all, or do you start with simple all-in-one-package and
refactor it later?
Thanks!
On Wed, 17 Oct 2007 15:15:58 +0200, Josip Gracin <······@tel.fer.hr> wrote:
> So, what I am looking for is an advice on using packages to organize
> code and namespaces in CL.
Not really advice, but you might want to look at some of the code from
Tim Bradshaw to see what one can do with packages:
http://tfeb.org/lisp/hax.html
HTH,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> Not really advice, but you might want to look at some of the code from
> Tim Bradshaw to see what one can do with packages:
>
> http://tfeb.org/lisp/hax.html
Thanks, I'll have a look at that.
Unrelated to your post, Edi, perhaps I should provide another typical
scenario in which I find myself in a dilemma. Here's an example.
In some code, I need a simple storage facility which will export the
following interface:
(store s key value)
(retrieve s key)
(erase s key)
(map-each-entry s fn)
Because their names are so common, the urge to put these four symbols in
their own namespace is very strong. The reasonable name for this
micro-package would be STORAGE, or STORE. However, writing
storage:store, storage:erase, etc. seems a bit tedious. (I see that
SBCL's coding style recommendations explicitly discourage such a style.)
What are my options?
On Wed, 17 Oct 2007 21:43:49 +0200, Josip Gracin <······@tel.fer.hr> wrote:
> In some code, I need a simple storage facility which will export the
> following interface:
>
> (store s key value)
> (retrieve s key)
> (erase s key)
> (map-each-entry s fn)
>
> Because their names are so common, the urge to put these four
> symbols in their own namespace is very strong. The reasonable name
> for this micro-package would be STORAGE, or STORE. However, writing
> storage:store, storage:erase, etc. seems a bit tedious.
What's wrong with /using/ (as in :USE or USE-PACKAGE) the package?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 17 Oct 2007 21:43:49 +0200, Josip Gracin <······@tel.fer.hr> wrote:
>
>> In some code, I need a simple storage facility which will export the
>> following interface:
>>
>> (store s key value)
>> (retrieve s key)
>> (erase s key)
>> (map-each-entry s fn)
>>
>> Because their names are so common, the urge to put these four
>> symbols in their own namespace is very strong. The reasonable name
>> for this micro-package would be STORAGE, or STORE. However, writing
>> storage:store, storage:erase, etc. seems a bit tedious.
>
> What's wrong with /using/ (as in :USE or USE-PACKAGE) the package?
Risk of conflict with another package? ERASE might easily be found in a
vector drawing package which I'd like to use at the same time, perhaps.
On Wed, 17 Oct 2007 22:31:04 +0200, Josip Gracin <······@tel.fer.hr> wrote:
> Risk of conflict with another package? ERASE might easily be found
> in a vector drawing package which I'd like to use at the same time,
> perhaps.
Cross the bridge when you come to it. You can shadow the conflicting
symbol for example.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 17 Oct 2007 22:31:04 +0200, Josip Gracin <······@tel.fer.hr> wrote:
>
>> Risk of conflict with another package? ERASE might easily be found
>> in a vector drawing package which I'd like to use at the same time,
>> perhaps.
>
> Cross the bridge when you come to it.
I guess I could get used to that tactic. It's not like conflict could
go unnoticed. So, simply :using packages until something gives and then
resolve the conflict by not :using one of the conflicting packages.
Not very elegant, but serves the purpose.
Thanks!
On Oct 18, 4:05 pm, Josip Gracin <······@tel.fer.hr> wrote:
> Edi Weitz wrote:
[...]
> > Cross the bridge when you come to it.
> I guess I could get used to that tactic. It's not like conflict could
> go unnoticed. So, simply :using packages until something gives and then
> resolve the conflict by not :using one of the conflicting packages.
> Not very elegant, but serves the purpose.
The package system is more finely grained than that. You can, for
instance, use the :SHADOW option for DEFPACKAGE to ensure that
specific symbols aren't imported from a package you're using. You can
also use :IMPORT-FROM to bring in specific symbols from a package
instead of using the whole thing, and so on.
You should definitely read the relevant section of the CLHS:
http://www.lisp.org/HyperSpec/Body/mac_defpackage.html
Cheers,
Pillsy
Pillsy <·········@gmail.com> wrote:
+---------------
| pm, Josip Gracin <······@tel.fer.hr> wrote:
| > Edi Weitz wrote:
| > > Cross the bridge when you come to it.
| >
| > I guess I could get used to that tactic. It's not like conflict could
| > go unnoticed. So, simply :using packages until something gives and then
| > resolve the conflict by not :using one of the conflicting packages.
...
| The package system is more finely grained than that. You can, for
| instance, use the :SHADOW option for DEFPACKAGE to ensure that
| specific symbols aren't imported from a package you're using. You can
| also use :IMPORT-FROM to bring in specific symbols from a package
| instead of using the whole thing, and so on.
+---------------
Indeed. Here's a little snippet of boilerplate I find myself using
whenever I play around with CLX while in the CL-USER package: ;-}
(require :clx)
#+cmu (shadow 'define-keysym)
#+clisp (shadowing-import 'xlib:char-width)
(use-package :xlib)
+---------------
| You should definitely read the relevant section of the CLHS:
| http://www.lisp.org/HyperSpec/Body/mac_defpackage.html
+---------------
And note especially the difference between the :SHADOW & :SHADOWING-IMPORT
options, and compare with the SHADOW & SHADOWING-IMPORT functions:
http://www.lisp.org/HyperSpec/Body/fun_shadow.html
http://www.lisp.org/HyperSpec/Body/fun_shadowing-import.html
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2007-10-17, Josip Gracin <······@tel.fer.hr> wrote:
> Let me just show an example of where I've been in my quest for the right
> way to use packages. In one of the schemes that I devised, I thought of
> using something like this
cl-package-aliases implements a scheme just like that for various Lisp
implementations (see http://www.cliki.net/cl-package-aliases).
(defpackage :foo
(:use :cl)
(:alias (:storage :st)
(:accounting :acc)))
d.
David Lichteblau wrote:
> On 2007-10-17, Josip Gracin <······@tel.fer.hr> wrote:
>> Let me just show an example of where I've been in my quest for the right
>> way to use packages. In one of the schemes that I devised, I thought of
>> using something like this
>
> cl-package-aliases implements a scheme just like that for various Lisp
> implementations (see http://www.cliki.net/cl-package-aliases).
>
> (defpackage :foo
> (:use :cl)
> (:alias (:storage :st)
> (:accounting :acc)))
Unfortunately, the link to the tar.gz file seems to be broken. Thanks
anyway!
On 2007-10-18, Josip Gracin <······@tel.fer.hr> wrote:
> Unfortunately, the link to the tar.gz file seems to be broken. Thanks
> anyway!
Try this one:
http://common-lisp.net/~dlichteblau/inofficial/cl-package-aliases-0.8+fix.tgz
Not the newest release, but the only version I could find.