[Haskell-cafe] Future Edison directions

[Robert Dockins]

Hello all,

There has been very recently a thread discussing the design decisions  
involved in creating a sequence abstraction.  This was naturally of  
interest to me as the current Edison maintainer, and generated a fair  
bit of interesting discussion.  I'd like to kick off a new thread  
here to talk about future directions for the Edison API in particular.

1) Regarding Sequence, I have become convinced by the discussion that  
the Edison Sequence class should be broken down into smaller  
classes.  Furthermore, it would be very nice to make these smaller  
classes shared across the various families of data structure  
abstractions in Edison (Sequences, Collections and Associative  
Collections).  The formulation of Sequence of kind * -> * may need to  
be sacrificed to this end.  I am not convinced that losing the maps  
and zips would be a major blow; however there are a couple of  
strategies for retaining them in some form.

2) The associated collection API is in a similar situation, except  
there are no zips.

3) I am reluctant to undertake a major overhaul of the Edison API  
while the future of type classes in Haskell' is so hazy.  I haven't  
heard any news from the Haskell' type classes focus group in quite  
some time, and last I was aware, discussion was somewhat stalled.  I  
there any hope for a coherent story here in the nearish future?

4) I am on the verge of deciding that nobody wants non-observable  
collections (ie, collections in which the element values are not  
available for inspection).  Currently Edison has no implementations  
which are non-observable, and I am not aware of anyone else creating  
a datastructure implementation in Haskell which is non-observable.   
Therefore, I am considering removing this feature of the Edison  
typeclass hierarchy to reduce complexity.  Shout if you think this  
would be a terrible mistake.

5) OTOH, something people DO seem to want is collection "views", or  
the ability to treat a datastructure as though it were something  
else.  For example, it would be nice to transparently treat the keys  
of a finite map as a set, or to treat a nested sequence as a single  
flattened sequence.  Such uses require the separation of operations  
which can create datastructures from those which merely inspect them  
(or some fancy bidirectional stuff I don't think I want to get into).

6) Edison 1.2 has now been out for a couple of months.  If you've  
used or looked at the new Edison, I'd love to hear what you think.  I  
think the next development cycle will involve pretty substantial  
changes, and if you want to get your gripes addressed, now is a good  
time to voice them.  Alternately, if you think there are some aspects  
that are very important to keep, that's also good information.

7) Finally, I somehow feel like there should be a nice categorical  
formulation of these datastructure abstractions which would help to  
drive a refactoring of the API typeclasses in a principled way,  
rather than on an ad-hoc I-sort-of-think-these-go-together sort of  
way.  Unfortunately, my category-fu is quite weak, so all I have is  
this vague intuition that I can't substantiate.  I'm sort of familiar  
with initial algebras, but I think they may be too concrete.  I'm  
looking for some way to classify algebras that have, eg, the property  
of having folds, or of being set-like, etc.  If anybody can point me  
in the right direction wrt this, that would be great.



Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG