And the third one I forgot at first: so far, all code I wrote could be easily ported to Hugs. On 16 Jun 2009, at 02:00, Miguel Mitrofanov wrote:
Probably.
I have two objections against using type families. Both are pretty much theoretical.
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 something. I'd be quite happy if list length appears as a separate parameter, like 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe