[Haskell-cafe] Why is $ right associative instead ofleftassociative?

[Bulat Ziganshin]

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 at HotPOP.com