sequences

Ross Paterson ross at soi.city.ac.uk
Tue Apr 13 12:03:49 EDT 2004


On Fri, Apr 09, 2004 at 03:04:16PM +0200, Wolfgang Thaller wrote:
> Ross Paterson wrote:
> >To have something concrete to discuss, I've placed a structure based on
> >Edison at
> >docs: http://www.soi.city.ac.uk/~ross/seq/
> >code: http://www.soi.city.ac.uk/~ross/seq.tar.gz
> 
> Looks nice. It's nice and simple, and I could start using it quickly, 
> without breaking too much of my code.
> Some naming nitpicks:

Noted, but the names are mostly from Edison, and are just placeholders.
The issue for the moment is whether the commonality between sequence
implementations should be expressed by a Haskell 98 Sequence class or
by a family of sequence modules that all export the same names.

> The main difference to Robert's approach, aside from his anti-list 
> propaganda ;-), seems to be that it uses a Haskell98-compatible 
> single-parameter type class.
> This means that concrete Sequence instances can't add an Ord context 
> later - Are we sure that there are no useful implementations of the 
> Sequence class that require their members to be instances of Ord? I 
> definitely can't think of any, but perhaps someone else can?

Yes, it's assumed that sequences are functors, which seems reasonable
to me.  It rules out treating unboxed arrays as sequences, but that
doesn't seem a priority.

> Also, we might really want to add an abstract collection framework 
> later; that will have to use MPTCs, and we will probably want Sequence 
> to be a subclass of that. Also, sooner or later we will move empty and 
> isEmpty to the general Collection class, won't we?
> Are there many people who will want to use the new framework but stay 
> with plain Haskell98?

The difficulty with trying to be compatible with a future abstract
collection framework is that there is no consensus on what that framework
should look like.  Which is why the recent effort has focussed on concrete
data structures.  We might as well pick the interface that works best
for sequences considered by themselves.  It should still be possible to
make these things instances of the classes of a Grand Unified Collection
Framework whenever it arrives.


More information about the Libraries mailing list