[Haskell-cafe] Re[2]: [Haskell] Proposal: unification of style of function/data/type/class definitions

Bulat Ziganshin bulat.ziganshin at gmail.com
Sun Sep 10 08:20:21 EDT 2006

Hello Neil,

Sunday, September 10, 2006, 2:21:50 PM, you wrote:

>> class Monad m | Functor m, Monoid m where ...
> It also makes grep'ing easier.

yes, i also had problems finding class declarations in base package

>> sequence :: [m a] -> m [a] | Monad m

> I don't like this. In the other two instances you are moving the most
> important information (the name of the thing) to the front. In this
> the name is at the front, but the instances move to the end, which
> isn't really where they should be. And following the function | rule

> function | predicates = body

> I would have said that logically, you want:

> sequence | Monad m :: [m a] -> m [a]

> (of course, this might present a problem for parsing...)

> Note this also makes sense compared to your:

> data Data | Classes = Alternatives

you have omitted "patterns, or parameters shape" part:

function shapes_of_parameters | guards_for_parameters = result

so, in my proposal:

data T a b | Eq a, Monad b = ....

and function signature obey the same rule - first write shape of
function type, then narrow type variables used to some classes:

addEncoding :: Encoding m -> h -> m (WithEncoding m h) | Monad m, ByteStream m h

Of course, that's more important is readability. it's discussible
whether we need to know that m is monad and h is stream before reading
shape of function type

btw, the following is anyway most readable:

sequence :: [Monad a] -> Monad [a]


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

More information about the Haskell-Cafe mailing list