suggestion: A common type class for mutable variables
ekmett at gmail.com
Mon Jun 3 22:00:34 CEST 2013
The inference can flow in either direction here. Haskell has no issue with
inferring the type of an input to a function based on the type of the
result. Type classes are pretty magical in that regard.
On Mon, Jun 3, 2013 at 3:22 PM, Petr Pudlák <petr.mvd at gmail.com> wrote:
> Dne 06/03/2013 09:11 PM, Henning Thielemann napsal(a):
> On Mon, 3 Jun 2013, Edward Kmett wrote:
> The first option is
> class Monad m => MonadRef r m | m -> r where
> newRef :: a -> m (r a)
> This has the benefit of using quite portable extensions.
> The second option is
> class Monad m => MonadRef m where type Ref m :: * -> *
> newRef :: a -> m (Ref m a)
> This takes us into GHC specific territory, by using type families, but
> avoids polluting every type that uses
> one with an extra 'ref' param. I use this variant in my as-yet-unreleased
> 'revisions' package.
> Both of these have the benefit that they can work with transformers, but
> they carry the limitation that you
> can't have multiple reference types for the same monad. e.g. you can't use
> the same combinators for both
> IORefs and, say, MVars or TVars within the same monad. This is arguably
> not so much a problem as they have
> very different operational semantics!
> I thought the functional dependency should be the other way round: From
> the reference type to the monad where it lives in.
> For monads, it's (AFAIK) always this way, because m is always in the
> result, but not necessarily the other type. Let's consider
> readRef :: r a -> m a
> In order to type-check x in readRef x, we need to determine r a from m a,
> so the dependency must be m -> r.
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries