[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