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