[Gardeners] Project Proposal: Standardized Utility Library

Thu Jun 8 11:47:01 CDT 2006

This sounds really good.

As a new lisper coming from the C#/ASP.NET world, and I think a lot of 
adoption lessons can be learned from the .NET framework, which is a 
mud-ball of epic proportions.  One thing that helps developers adopt C# 
is decent documentation and the availability of sample code.  (having it 
be the only option also helps)

I think in order for experienced lispers to adopt a library for a 
utility function, it just needs be easier to find, install, and use the 
library than to write the utility function.  Having good googleable HTML 
documentation will make it easier to find utilities, and from the list 
below, thats in the plan.

In order for new lispers to adopt a library, I believe sample code is 
essential.   I think a lot of new lispers are coming from  .NET, Java, 
Python, or PHP, which all have standard libraries and code samples 
galore.  We're used to including massive black-box libraries in our 
applications and looking up the sample code.  I can google many common 
tasks (eg "php email attachments") and come up with samples of how to do 
it with C#, Java, Python, and PHP in the first page of results.  It 
helps us a lot to see a function used in context.

As a side note, I think some of these goals might overlap with work on 
http://enterpriselisp.com and http://cl-user.net, and there might be 
some reuse available.

Thanks,

Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506

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
> Gardeners at lispniks.com
> http://www.lispniks.com/mailman/listinfo/gardeners
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lispniks.com/pipermail/gardeners/attachments/20060608/39e8cbcd/attachment-0001.html