sequences

[Robert Will]

On Tue, 13 Apr 2004, Ross Paterson wrote:

> 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.

We just need to agree that the framework will use MPTC.  (I think there's
no other choice, since Ordered Collections have to put their "Ord a"
context somewhere.)

Then we can easily make the Sequence a subclass of class Collection later,
lifting some functions up.  No problem here.

> 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.

I add the question: if we have the 'Sequence' class, should we also have a
superclass 'Collection' with some operations that are indepent of the
explicit element ordering provided by Sequences?

> Grand Unified Collection Framework whenever it arrives.

Since we already have a concrete proposal with prototype implementation,
that "whenever" may not be so far away.  Especially I think that the
uncertainities of the Ordered Collections (see section on ByMaps in the
documentation), are independent of the design for the Sequence and
Collection classes.  So I do think that we can already rely on those
classes being a good approximate of a future standard, if there will be
one.

Most notably my design rationale argues that some disadvantages of my
proposal (long type signatures, MPTC, restricted laziness...) are
necessary to any sensible Collections Framework.  So it we don't accept
those, we should agree that there will _never_ be such a Framework.  Or
perhaps anyone can refute my argumentation?

Robert