[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell
Subject:    [Haskell] ANNOUNCE: container-classes-0.0.0.0
From:       Ivan Lazar Miljenovic <ivan.miljenovic () gmail ! com>
Date:       2010-07-18 7:29:26
Message-ID: 87hbjxcko9.fsf () gmail ! com
[Download RAW message or body]

I'm pleased to announce the fruits of my labours during AusHac [1]:
version 0.0.0.0 of the container-classes library [2] I was talking about
in my last blog post [3].

[1]: http://www.haskell.org/haskellwiki/AusHac2010
[2]: http://hackage.haskell.org/package/container-classes
[3]: http://ivanmiljenovic.wordpress.com/2010/07/14/data-oriented-hierarchies/

The purposes of this library is two-fold:

* As a library writer, let your users choose which data structure they
  want to use rather than whichever one you decided upon when writing
  the library (e.g. you use lists predominantly, but your users may want
  to use Sets; by outputting a generic Container value yoru users don't
  need to keep using Set.fromList and Set.toList).

* When writing your own code and you realise that you're using the wrong
  data structure for your purposes, if you used this library (correctly)
  then the amount of work you need to do to swap data structures is
  minimised.

This current version is only a first draft.  As such, I would appreciate
feedback on the API.  Currently, it provides its own definitions of all
list-oriented functions in the Prelude plus a few more (e.g. partition),
and list instances of all the classes.

In terms of definitions, most class methods have default definitions in
terms of fold.  Furthermore, as much as possible I've defined them using
a build/fold setup outlined in the paper "A Short Cut to Deforestation"
by Andrew Gill, John Launchbury and Simon Peyton Jones (however I
haven't yet defined the rules to get this used yet).  However, the
current list instances use the pre-defined versions in the Prelude and
Data.List; I'm not sure if I should keep it this way or - where
equivalent - use the pre-defined ones so that hopefully conversions from
lists to other data types would also be removed without needing
intermediary data structures.

I also plan on adding more instances and a Lookup class for Maps, etc.
However, we have to start packing up the room now and so my hacking is
at an end for this weekend :(

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[prev in list] [next in list] [prev in thread] [next in thread]