Hello Lennart, Sunday, February 05, 2006, 5:12:48 PM, you wrote: LA> In my opinion all the special syntactic sugar for lists should go LA> away. I don't think lists are special enough to motivate it. i have proposal (not for Haskell', of course) of using ":" and "[]" syntax for general notion of traversable collections: JM> What do people think about seperating the class and type namespaces? one i have exactly opposite idea - give the class and type names equal rights :) instead of writing foo :: (Num a, Monad m) => a -> m () allow to write foo :: Num -> Monad () and vice versa - instead of bar :: Int -> [Int] allow to write bar :: (Int a, [] b) => a -> b a That this gives? 1) significantly simplifies declarations using typeclasses. i was seriously bitten by those huge declarations, and think that simplification in this area will lead to much wider use of type classes by the ordibary users (like me :) . ideally, i just don't need to think whether a Foo is a class or type in most cases - both can be used interchangeably (like interfaces and classes in Java) 2) this allows to refactor existing code without changing type signatures. just for example - imagine that [] is now a typeclass implementing only several basic operations, namely head/tail/(:)/null. nevertheless, all those huge number of list-processing functions still work because [] in their type signatures now means that parameter/result belong to the some instance of this class. cool? i think so :) of course, that also need possibility to define pattern matching (meaning of []/a:b) inside this class, but that's a different proposal :) two uses of the same class in one declaration should mean the same type, as in: reverse :: [a] -> [a] what is equivalent to reverse :: ([] c) => c a -> c a Of course, refactoring of [] is just amazing example. what i basically mean - when program grows and some T becomes an interface instead of type, there should be no need to change all the T usages - they will continue to work, work and work. The only exception will be type signatures, where T is used ywo times or more and different T's usages can mean different types. in this case, we need to switch to expanded signature, what nevertheless should work even if T is still just a type: cvt :: (T a, T b) => a->b JM> this would allow things like one to have a class and a data type holding JM> an arbitrary member of said class to have the same name _may be_, my proposal can even solve your problem -- Best regards, Bulat mailto:bulatz@HotPOP.com