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
