ANNOUNCE: container-classes-0.0.0.0

[Ivan Lazar Miljenovic]

I was in a bit of a rush to send this email earlier before the table got
packed up from in front of me, so I forgot to mention these little
tidbits:

* container-classes uses MPTCs+fundeps to define the classes rather than
  type families.  My initial preference would have been to use an
  associated type, except that due to the lack of superclass constraints
  then the various *Functor type classes would have to have extra
  constraints of the form "Value (c a) ~ a" in every single type
  signature (and for every single value being used, so 3 extra
  constraints of this form for zip3, etc.).  I felt that this verbosity
  was a bit too much and thus declined.  Furthermore, I would have
  needed to use an MPTC for the *Functor type-classes anyway as I would
  have to state the value type somewhere in the class to ensure it was
  properly constrained.  However, once superclass constraints become
  available (which will probably be 6.16 at the earliest from what I've
  been told) then I'll switch it to using type families (assuming the
  library is still being used of course).

* Container uses Monad as a super-class to avoid re-defining mempty and
  mappend, though it does have (++) = mappend, so that's there for all
  those people wanting to infiltrate Caleskell-style ideas into Haskell
  proper...

* Someone's asked me why I don't define a Traversable-like class.  The
  reason is is that I haven't gotten around to it yet ;-) (as well as a
  great many other things).

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> writes:

> 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 at gmail.com
IvanMiljenovic.wordpress.com