RFC: general sequences

[Benjamin Franksen]

On Tuesday 24 May 2005 11:00, Henning Thielemann wrote:
> On Tue, 24 May 2005, Ross Paterson wrote:
> > On Mon, May 23, 2005 at 10:22:38PM +0200, Benjamin Franksen wrote:
> >> A agree completely. Almost all of the functions in Data.Seq have
> >> the same name and type signature (modulo the data type) and
> >> provide the same functionality as the corresponding ones for lists
> >> (in the Prelude). A type class Sequence to capture these common
> >> features would be great. It would also mean we can import module
> >> Sequence unqualified. A problem is that the names conflict with
> >> the ones from the Prelude, so that this style can only be used
> >> when hiding all the list stuff from Prelude.
> >
> > This can't be fixed by adding a new class.  We can't change the
> > type of Prelude.length, and that includes generalizing it.  The
> > only alterative to hiding/qualification is to give our functions
> > different names.
>
> What is so bad about qualification? Although it might be cumbersome
> for everyday functions like 'map' and infix operators it's good style
> for any other functions. With qualification a user module would look
> like
>
> import qualified SomeGoodNameForASequenceClassModule as GenSeq
> import qualified Data.Sequence as Seq
>
> filterEven :: GenSeq.C s => s Int -> s Int
> filterEven = GenSeq.filter even
>
> filterEven' :: Seq.T Int -> Seq.T Int
> filterEven' = GenSeq.filter even

Do you want to write such wrappers for each 'everyday' function from -- 
say -- Set, Map, Seq or similar standard collection modules? Surely 
not.

You have answered your question yourself: Qualified import is bad for 
everyday functions like 'map' and also for operators. The problem with 
'map' is that it is restricted to lists and not available for other 
collections. I think 'filter' is an everyday function like 'map'. All 
these should be members of appropriate type classes.

That doesn't mean I am against qualified imports. I personnally think 
qualified import is good for libraries that serve a special purpose, 
for instance a GUI library or a /special/ implementation of some data 
structure. I think it is less appropriate for the standard collection 
ADTs that should be available for everyday use in the most easy-to-use 
manner. Type classes are a lot easier to use, because the compiler 
selects the correct instance, not the programmer.

Ben