Peter, thanks for the permission to include monkeylib and twas!  I'll
start there after I've talked to the cl-utilities owner to see if he
wants in (or out) of the project.  Any concerns or preference on a
license?  (MIT vs. LLGPL?)  Any advice on handling copyright and author
attribution?

I think the inclusion of a standard utilities distribution in Lispbox
would be very helpful to building some momentum.  The other action we
could take as a gardening effort is adapt some existing asdf packages
with internal utility libs to rely on the standard library so that it is
included on more systems by contamination.  That makes the inclusion of
it in new projects a lower-cost effort.  (Elephant, for instance, only
has a few utilities because we wanted to avoid on non-standard outside
libraries as much as possible.)

Indexing & Documentation:

As I've been thinking about this project, it occurs to me that the
downside of a standard library is that it often takes a long time to
learn what utilities are available for a problem you're trying to
solve.  Since I wrote or imported most of my utilities to solve a
problem, I have a use case in my memory so know what's out there to
use.  Sometimes, when I try to solve a problem, I'm sure someone else
has solved it but I can spend quite a bit of time trying to find and
adapt that solution.  This is made harder, in part, by lisp's
flexibility and by the somewhat incoherent nature of the community.  So
far I've failed to get my students to use all but the most obvious few
utilities in our development tree and I think the biggest problems is
getting from a programming problem to the tools best suited to solve
it.  It's not having documentation so much as it is finding what
utilities are likely to be relevant to your problem.  The search
function is probably the most important part of this effort to avoid the
kind of over-structuring, one-way-to-do-it that is so rampant in the
Java community.

Some steps:
- Web service: provide a web search interface to do completion/search
(with a little ajax magic)
  1) over all loaded simple utilities using normal slime completion modes
  2) index by keywords in documentation strings, motivating verbose doc
strings
  3) link to example uses?  Can this be done automatically to the
Cookbook or using xref info on the current image?
- SLIME integration: integrate #1 and #2 into a SLIME "code browser"
function.  I think the SLIME folks would
  support a general solution where you can pre-compute an index file or
online compute it from the current image
  for some set of packages.

I don't want to set out to ambitious a goal before there is anything
there to talk about, but if there are some good ideas for low hanging
fruit on the search/indexing front I'm willing to pursue them up front.

Cheers,
Ian


Peter Seibel wrote:
> On Jun 4, 2006, at 4:43 PM, Ian Eslick wrote:
>
>> Here is a project proposal that I'm willing to champion and support.  I
>> am constantly frustrated by each large project I download also coming
>> with a their own versions of of various common utility functions such as
>> Graham's anaphoric macros (aif, awhen), common list utilities (gather,
>> distribute, shuffle, merge, etc) and so on.  My lisp image is getting
>> filled up with duplicated code between CL-SQL, UCW, CLOCC, and my own
>> local utilities.  It's also annoying that if I want to keep something
>> portable I have to revert to using standard lisp and forget about the
>> hundreds of little time and thought-saving utilities I've developed for
>> my private packages.  I figure I can't be the only one.  This may
>> overlap with the CLOCC project but I find that project is badly
>> organized, poorly licensed and not actively maintained.
>
> +1. If you want an easy way to grab the latest versions of my
> libraries (some of which grew out of PCL) you can get them at:
>
>   <http://www/www.gigamonkeys.com/lisp/monkeylib-0.3.204.tar.gz>
>   <http://www/www.gigamonkeys.com/lisp/twas-0.1.165.tar.gz>
>
> (Monkeylib now depends on Twas--one of these days, I'll merge them if
> this project doesn't make them both superfluous.)
>
> Also, I'd be happy to start including this set of libraries in
> Lispbox, which should make Lispbox more useful and lower the barrier
> to getting started for new Lispers.
>
> -Peter
>
> --Peter Seibel           * [EMAIL PROTECTED]
> Gigamonkeys Consulting * http://www.gigamonkeys.com/
> Practical Common Lisp  * http://www.gigamonkeys.com/book/
>
>
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners

Reply via email to