Edison RC3

Robert Dockins robdockins at fastmail.fm
Tue Apr 4 19:50:41 EDT 2006

Fellow Haskellers,

The 3rd release candidate for Edison 1.2 is now avaliable.  URLs to the 
project will appear at the end of this message.

As with previous pre-releases, I am requesting comments on the API in 
particular.  I believe I am approaching the point where I will feel 
comfortable freezing the 1.2 API, and I hope this will be the last release 
candidate before a 1.2 final.

Major changes in 1.2rc3 are:

  * introduce the ambiguous/unambiguous concept and document
    all API operations
  * factor out methods which "mirror" superclass methods and
    make them alises instead
  * add lookupAndDelete* methods to associated collections
  * change the type of adjustOrDelete* in associated collections
  * rename subset/subsetEq to properSubset/subset
  * add matching Read and Show instances for all concrete datastructures
  * add properSubmap{By} submap{By} and sameMap{By} to the
    associated collection API
  * add Eq instances for concrete associated collections
  * break out the test suite into a separate sub-package

The major remaining API issues I wish to request comments about have to do 
with class instances:

1) RC3 introduces Read and Show instances for all native Edison 
datastructures.  However, StandardMap and StandardSet are just type aliases 
for Data.Map and Data.Set -- thus I can't provide Read and Show instances 
that are similar.  So the question is, should I instead newtype these 
implementations so I can provide class instances which are consistent (as 
well as any other class instances I end up providing)?

2) Regarding Typeable and Data, what are your thoughts about the best way to 
provide Typeable and Data instances over abstract data types?  I've 
considered playing the same trick that I do for Read/Show (which is internal 
conversions to/from lists).  What do you think?

3) Are there any other class instances that are important to supply?

And one final meta-API question; what are your thoughts about portability in 
general?  I would like to support as many implementations as possible, but 
I'm already relying on MPTC, fundeps and undecidable instances (which may or 
may not be in H'), and I'm considering the following:

-- instances of Typeable/Data (listed as non-portable)
-- assertions (for checking preconditions)
-- newtype deriving

Anyway, I'm interested in your thoughts about how important portability is.

How to get Edison:

Project page:


Source tarball:

Darcs repo:

Rob Dockins

More information about the Libraries mailing list