Package extensions usage

Pascal Costanza pc at p-cos.net
Wed Dec 30 01:25:42 UTC 2015


Hi,

1) I believe package-local nicknames are very useful. Being able to use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.

2) I don’t believe hierarchical package names are useful. That’s a Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;). Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.

Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.

My primary CL implementation is LispWorks, so I don’t use package-local nicknames in practice, but I have used other languages with similar features (most notably Oberon), and they were just very handy.

I hope this helps.

Pascal

> On 30 Dec 2015, at 00:56, Kenneth Tilton <ken at tiltontec.com> wrote:
> 
> Packages are over-rated. We lived (and suffered) with packages for months and when I finally rolled everything up into one package it presented zero problems and ended a steady stream of problems. As one Lisp venerable said, "It was a package problem. It is always a package problem." 
> 
> On Tue, Dec 29, 2015 at 6:52 PM, Alessio Stalla <alessiostalla at gmail.com <mailto:alessiostalla at gmail.com>> wrote:
> Hi everyone,
> 
> I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.
> 
> So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:
> 
>  * package-local nicknames: the ability to specify, for each package, a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL (http://www.sbcl.org/manual/#Package_002dLocal-Nicknames <http://www.sbcl.org/manual/#Package_002dLocal-Nicknames>) and possibly other implementations I'm not aware of.
>  * "Hierarchical" packages: a naming convention for packages understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm <http://franz.com/support/documentation/current/doc/packages.htm>) and in an open-source library by P. Bourguignon.
> 
> My questions:
> 1) First and foremost, is anybody actually using those features? What are you using them for?
> 2) If yes, how useful are they for you? What shortcomings do you find in them?
> 
> 
> 
> -- 
> Kenneth Tilton
> 54 Isle of Venice Dr
> Fort Lauderdale, FL 33301
> 
> ken at tiltontec.com <mailto:ken at tiltontec.com>
> http://tiltontec.com <http://tiltontec.com/>
> @tiltonsalgebra
> 
> 646-269-1077
> 
> "In a class by itself." -Macworld
> 
> 

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20151230/b22b0dba/attachment.html>


More information about the pro mailing list