suggestion: A common type class for mutable variables

Edward Kmett ekmett at gmail.com
Mon Jun 3 21:03:51 CEST 2013


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!

In other code I've done horrible things for lifting TVars out into monad
transformer stacks, while well aware of the rather ad hoc meaning of chains
of operations on TVars when you are working over something IO based.
Peeking at some haddocks from my analytics project:

class Monad<http://rebase.org/Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/share/doc/ghc/html/libraries/base-4.5.0.0/Control-Monad.html#t:Monad>
m
=> MonadSTM m whereSource<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#MonadSTM>

stm :: STM<http://rebase.org/Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/share/doc/ghc/html/libraries/base-4.5.0.0/GHC-Conc.html#t:STM>
a
-> m aSource<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#stm>

newTV :: a -> m
(TVar<http://rebase.org/Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/share/doc/ghc/html/libraries/base-4.5.0.0/GHC-Conc.html#t:TVar>
 a)Source<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#newTV>

readTV :: TVar<http://rebase.org/Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/share/doc/ghc/html/libraries/base-4.5.0.0/GHC-Conc.html#t:TVar>
a
-> m aSource<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#readTV>

newTMV :: a -> m
(TMVar<http://rebase.org/Library/Haskell/ghc-7.4.1/lib/stm-2.3/doc/html/Control-Concurrent-STM-TMVar.html#t:TMVar>
 a)Source<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#newTMV>

newEmptyTMV :: m
(TMVar<http://rebase.org/Library/Haskell/ghc-7.4.1/lib/stm-2.3/doc/html/Control-Concurrent-STM-TMVar.html#t:TMVar>
 a)Source<http://rebase.org/analytics/src/Data-Analytics-Task-STM.html#newEmptyTMV>

newTC :: m (TChan<http://rebase.org/Library/Haskell/ghc-7.4.1/lib/stm-2.3/doc/html/Control-Concurrent-STM-TChan.html#t:TChan>
 a)

This had the benefit of staying in 98 style, but solved a different problem
than what we're discussing here, because the reference type was fixed.

In yet other code i've had the reference type select the monad it works
with. The primitive package that is used by vector is at least morally of
this flavor, though, for array types rather than references, but another
example is the 'var' package that was released the other day in response to
this thread. It doesn't use any functional dependencies between the monad
and the reference type in order to support multiple reference types per
monad, including unboxed variants.

-Edward


On Mon, Jun 3, 2013 at 2:38 PM, Petr Pudlák <petr.mvd at gmail.com> wrote:

>  Could you please just shortly comment about those two? I'd be interested
> to know.
>
> Thanks, Petr
>
> Dne 06/03/2013 08:32 PM, Edward Kmett napsal(a):
>
> I see little hope in standardizing as, heck, I personally have felt the
> need to use two of the different points in the design space within just my
> own code.
>
> -Edward
>
>
> On Mon, Jun 3, 2013 at 2:13 PM, harry <voldermort at hotmail.com> <voldermort at hotmail.com> wrote:
>
>
>  Henning Thielemann <lemming <at> henning-thielemann.de> writes:
>
>
>  I have started a Wiki page in order to keep an overview of all the
> existing approaches:
>    http://www.haskell.org/haskellwiki/Mutable_variable
>
>  There seems to be a fair amount of duplication in all this ... any idea how
> a "standard" approach could be selected?
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130603/b58290db/attachment-0001.htm>


More information about the Libraries mailing list