This is a nice writeup. Just not to let a lot of work being lost to the masses, please note that the CLURFI discussion list has covered some of this ground. (I was on the loosing side)
People may criticize it or not, but I believe that my proposal for organization of "extension libraries" and "package naming" went a long way to ensure that two different implementation of a contribution were possibly caught by a CL trying to load two different implementations of the same functionality. On top of that, I believe that for most part, the organization of contributions should follow the chapter structure of the ANSI spec, with possible additions for other things not present there (insert the usual suspects here: multiprocessing, networking, etc etc) Cheers Marco On Jun 8, 2006, at 5:13 PM, Ian Eslick wrote: > Great discussion these past two days, let me see if I can capture the > input in the form of an updated proposal: > > Distribution and name space > ------------------------------------ > > My idea was to avoid too much required pollution of the namespace by > providing different options for importing library names. We break the > library up into multiple conceptually related groups of functions but > allow those names to be imported all at once (stdutils.all), by area > (stdutils.io, stdutils.math), or individually (stdutils.ctrl.if*). > > The second problem is polluting your image with a huge amount of code > you don't need. Now lisp is so big in most cases that no one is likely > to notice, but some folks might want flexibility. So again we have a > default model and leave an option for experts. If you release a single > tarball and a single asdf entry point you can still break it into > subprojects that can be loaded separately (asdf:operate 'asdf:load-op > :stdutils.math) vs. (asdf:operate 'asdf:load-op :stdutils) > > Upgrades polluting namespace. Versioned import will keep the namespace > from getting polluted upon upgrades. We should also make it easy to > craft your own utilities import so you can write an application-local > file that builds and imports just the stuff you need. Lots of little > files in the stdutils distribution will make this easier. The standard > approach will be that you get all the basic stuff as part of using > stdutils but have to import larger packages explicitly. > > > Versioning > -------------- > > While we will try hard to limit the standard library to highly stable > and mostly single-function utilities there will undoubtedly be > versioning issues as the library evolves, fixes bugs, enhances features > and such. However if many people are to depend on it (libc) we should > consider a commitment to users on upgrading the library. On the whole, > I would support a model where strong argument is needed for changing a > function's behavior and that importing a new distribution can be done > without changing any existing code but that new functionality can be > imported on a per-function basis (import statements) or by switching > the > use-package to the new global version number. > > Documentation > -------------------- > > Library has a standard documentation model for how functions are > documented. This should enable automatic generation of PDF and HTML > for > browsing, searching & reference. > > Decision making > --------------------- > > I find that having a straw man system to explore, critique or patch > works better than higher level discussions. I have a local repository > where I've already integrated my group's utilities as well as anaphora, > selected parts of monkeylib, etc. I have family in town this weekend > but would like to release an alpha version of 'stdutils' for people to > experiment with and critique late next week or next weekend. If anyone > would like to submit something to this initial release, please send me > a > tarball or a pointer. > > Would anyone like to volunteer to put together a strawman model of the > package versioning we've discussed? (Thanks to Nikodemus Siivola for > the draft code!) I should have time to take a pass at it myself but I > have alot of other things to do as well so some dedicated effort could > go a long way. > > Ian > > Pascal Bourguignon wrote: >> Luís Oliveira writes: >> >>> I see many projects trying to avoid dependencies (and therefore >>> duplicating code). Being able to depend on the "Standard Library" >>> would >>> probably make authors/maintainers not worry so much about that. Does >>> this make any sense at all? >>> >> >> We'd still have to resolve the version problem first. >> >> For application code, it wouldn't matter to depend on a "standard" >> library. >> >> But for a library, this is problematic, since another library may >> depend on another version of the same "standard" library. Therefore, >> both libraries couldn't be used in the same core image for the >> conflict on the "standard" library version. >> >> With NIH this is resolved somewhat inelegantly, but effectively: >> there's little code that depends on my own utility library, so when I >> make an incompatible change to it, I can easily enough update all my >> other programs using it (but not always so easily, so I keep snapshoot >> _copies_ of my utility libraries with deployed applications!). >> >> >> >> You'll have to "extend" the packaging system of Common Lisp first. >> >> - hierarchical packages (see Franz's), >> - package nicknames relative to the current package, >> - package versions. >> >> >> >> (in-package :p1) >> (use-package :com.informatimago.common-lisp.avl :version '1.2.1 :as >> :avl) >> (avl:insert *tree* *element*) >> >> (in-package :p2) >> (use-package :cl.extensions.avl :version '1.0.newest :as :avl) >> (avl:insert *tree* *element*) >> >> (in-package :p2 :version "2.0") >> (use-package :cl.extensions.avl :version '1.0.newest :as :avl1) >> (use-package :cl.extensions.avl :version '2.1.newest :as :avl2) >> (avl1:map-tree (lambda (e) (avl2:insert *tree-2* e)) *tree-1*) >> >> >> (Versions could be added to the package names: >> p2.2.0 >> cl.extensions.avl.1.0.newest >> cl.extensions.avl.2.1.3 >> cl.extensions.avl.2 >> cl.extensions.avl.2.newest ; the last three names could refer the >> same >> ; package in a given image. >> ) >> >> >> >> > _______________________________________________ > Gardeners mailing list > [email protected] > http://www.lispniks.com/mailman/listinfo/gardeners > -- Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
