[Haskell] Long live Edison
Robert Dockins
robdockins at fastmail.fm
Mon Feb 20 16:22:19 EST 2006
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
More information about the Haskell
mailing list