[Haskell] Long live Edison

[Robert Dockins]

Sorry for replying to myself....

> Haskell community,
>
> As many of you are aware, Edison is a venerable library of data  
> structures written in Haskell, primarily by Chris Okasaki.  I have  
> though for some time that it is a great shame that Edison has been  
> languishing in disuse.  It has always seemed to me to be high  
> quality code which is fairly well designed.  I believe that the  
> barriers to its adoption have largely been barriers of ease-of-use  
> and project management, and not necessarily problems with the  
> design or implementation of the code itself.
>
> Although I am not a data structures expert, several weeks ago I  
> decided that I would try my hand at maintaining Edison and see if I  
> could overcome these barriers.  Toward this end I have taken the  
> most recent Edison codebase I could find (from Andrew Bromage's HFL  
> project) and updated it in the following ways:
>
>
> -- Put source code under darcs version control
> -- Moved modules into a module hierarchy rooted at "Data.Edison"
> -- Moved to a cabal build system
> -- Integrated documentation into the source code using Haddock
> -- Tied together the various unit testing code into a comprehensive  
> test suite
> -- Altered the API to bring it more closely in line with current  
> practice (as exemplified by the Data.Set and Data.Map standard  
> libraries)
> -- Added Data.Set and Data.Map as Edison "implementations"
>
>
>
> I now feel that it is ready for release, and have consequently  
> prepared what I am calling "Edison 1.2, release candidate 1".   
> Before I officially dub Edison 1.2, I would like to request some  
> feedback from the community.  In particular, I would very much like  
> to hear people's opinions about the API: naming conventions,  
> argument orders, etc.  I have already made a number of changes to  
> the Edison 1.1 API, and if people feel other changes are warranted,  
> I'd like to go ahead and make them all at once.
>
> Particular points about which I would like to get feedback are:
>
> -- The Sequence 'rcons' method takes its arguments in the opposite  
> order as the 'lcons' method (for mnemonic purposes).  Should the  
> arguments to 'rcons' be reversed?
> -- There are a few places where 'Data.Map' and/or 'Data.Set' have  
> methods named similarly (but not identical) to the Edison API.  By  
> and large I have left those differences.  Should I instead modify  
> Edison to match those names?
> -- Are there additional methods that should be added to the API?
> -- Are there methods that should be removed?

One additional point I just remembered:

There are a number of methods which take a monad context and call  
'fail' (rather than error) under some conditions, usually when the  
data structure is empty, e.g.

lview :: Monad m => s a -> m (a, s a)
Separate a sequence into its first (leftmost) element and the  
remaining sequence. Calls fail if the sequence is empty.

I am considering moving to a MonadPlus context and calling 'mzero' in  
the failure case.  For the Maybe and List monads, the results are the  
same.  In general I like using MonadPlus better, but mplus doesn't  
take a string message like fail does.  Thoughts?


> And perhaps most important,
>
> -- looking at this version of Edison, are there any things that  
> would make you hesitant to use it?
>
>
>
> You can find Edison 1.2rc1 at the following places:
>
>
> Project homepage:
> http://www.eecs.tufts.edu/~rdocki01/edison.html
>
> API docs:
> http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html
>
> Darcs repository:
> http://www.eecs.tufts.edu/~rdocki01/edison/
>
> Source tarball:
> http://www.eecs.tufts.edu/~rdocki01/projects/edison-1.2rc1- 
> source.tar.gz
>


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell/attachments/20060220/2a7ddccb/attachment.htm