Hi, Tobias,
Yes, there is. A monad is a functor by definition, so it has to accept
a type to produce another type. It can't be represented in another
way, at least in Haskell. You can't come up with a sensible definition
of a functor without HKT:
class Functor (f :: *) <probably something else> where
fmap :: (a -> b) -> f -> f -- ???
The above does not make sense at all: you can't specify relationship
between a and b in f's codomain, and additional parameters to the type
class won't help.
Similarly, you cannot make a monad without HKT too.
MPTCs with functional dependencies are used in Haskell only to create
monad *transformers*. In fact, it is possible to create transformers
without MPTCs+FDs (and without type families), but they will be very
inconvenient to use - you won't be to obtain transformer operations
like (get :: StateT s m a -> s), (ask :: ReaderT r m a -> r) and
others for your monad stack for free.
2014-03-01 2:54 GMT+04:00 Tobias Müller <[email protected]>:
> Eric Reed <[email protected]> wrote:
>> In general, monads require higher-kinded types because for a type to be a
>> monad it must take a type variable. That is, Option<T> and List<T> could
>> be monads, but int and TcpSocket can't be monads. So imagine we wanted to
>> define a trait Monad in Rust.
>
> Just for my understanding. Is there an inherent reason that a monad has to
> be a higher kinded type (type constructor)? Couldn't it also be represented
> somehow as a multiparam trait/typeclass?
> AFAIK, higher kinded types are standard haskell, while MPTCs are not, so
> it's the obvious choice for haskell. Is it also for rust?
>
> Tobi
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
