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?
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.
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?
