"class []" proposal Re: [Haskell-cafe] One thought: Num to 0 as ? to list?

[Bulat Ziganshin]

Hello Malcolm,

Tuesday, August 22, 2006, 4:22:50 PM, you wrote:

>> 2) allow to use type classes in type declarations like the types
>> itself. for example, allow the following:
>> 
>> f :: Num a => a -> Int
>> write as
>> f :: Num -> Int
>> 
>> and following:
>> 
>> sequence :: Monad m => [m a] -> m [a]
>> write as
>> sequence :: [Monad a] -> Monad [a]

> How would you distinguish the class contexts of (for instance)
>     sequenceLift :: (Monad m, Monad r) => [m a] -> r [a]
> if it were to be written instead as simply
>     sequenceLift :: [Monad a] -> Monad [a]

> And how would one add multiple class constraints to a single type
> variable, for instance in:
>     f :: (Functor m, Monad m) => (a->b) -> m [a] -> m b

both your examples cannot be written using proposed syntax

what i propose is not full replacement of existing syntax - quite the
contrary it is just a syntax sugar for most frequent cases of using
classes in function signatures. the key idea is that in most cases we
use only one type class for each type variable, and the same type for
each occurrence of type class in the type:

(+) :: Num -> Num -> Num

This also simplifies the case when programmer has developed his code
with one concrete type in mind and later decided to transform it into
typeclass. In this case my idea allows to retain old definitions in
most cases (and promoting [] to type class is very typical example
here! we can browse prelude/list module and count how many definitions
need to be changed if [] becomes type class)

This proposal born from my experience of using type classes to make
Streams library more flexible. i found that type signatures using type
classes becomes larger and less readable and thought that they can be
made no more complex than ordinary ones by using this idea. Java/C++
also allows to specify names of abstract classes/interfaces instead of
concrete classes. Haskell's benefit is that general syntax allows to
express more complex restrictions. I propose to combine it with the
OOP-like simple syntax for simple cases (which is 80-90% of total ones)

so, while this proposal is rather minor, i think that it is Good thing


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com