[Haskell-cafe] Re: Parametrized monads
miguelimo38 at yandex.ru
Mon Jun 15 18:00:25 EDT 2009
I have two objections against using type families. Both are pretty
First, it seems to me that using type families would require some
other extensions. Multi-parameter type classes are OK, but, in my
experience, the road from them to the darkness of undecidable
instances is quite short, and I don't feel very safe on these grounds.
Maybe it's just me, but I can't help imagining myself adding just one
element to the already long list, and the compiler throwing tons of
cryptic error messages on my head because the derivation of necessary
instances is just too long. It happened before, and I still don't know
how to prevent it.
Secondly, type families are one thing that I have no idea of how to
abstract if needed. I know how to abstract a usual type class - by
passing the dictionary explicitly, for example; there are some more
sophisticated methods like higher-level monad - but it seems almost
impossible to abstract a class that can have an associated data type.
I don't see any reason to do this - yet; and for me, "yet" is enough
to make me nervous.
On 16 Jun 2009, at 01:25, Ashley Yakeley wrote:
> Miguel Mitrofanov wrote:
>> Suppose I want to create a specific monad as a combination of monad
>> transformers - something like "StateT smth1 (ReaderT smth2
>> Identity)". As you can see, each transformer is parametrized with a
>> type of kind *. I want to abstract these parameters, so that
>> instead of "StateT smth..." I can write something like
>> Zip (ConsT StateT (ConsT ReaderT NilT)) (ConsA smth1 (ConsA smth2
>> NilA)) Identity
>> and it would be a type isomorphic to the first one. I mean, I want
>> (ConsT StateT (ConsT ReaderT NilT))" to be a separate entity of
>> fixed kind, so that I can, say, create a class instance for it or
>> I'd be quite happy if list length appears as a separate parameter,
>> Zip (Succ (Succ Zero)) (ConsT ...
>> I would NOT be happy with something like
>> Zip (List_2 StateT ReaderT) (Arg_2 smth1 smth2)
>> If haskell had polymorphic kinds, I'd be able to do it easily;
>> unfortunately, it doesn't have them.
> I think the "type families" extension can do this.
> Ashley Yakeley
More information about the Haskell-Cafe