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