Is there any particular reason there isn't a class for monads for which things like IORef/STRef exist? I suppose the naive approach would require functional dependencies + mp typeclasses[1], which is a decent reason :), but has anyone come up with something that doesn't require extensions? [1] i'm thinking of something like: class MonadRef m r | m -> r, r -> m where newRef :: a -> m (r a) readRef :: r a -> m a writeRef :: r a -> a -> m () updateRef :: (a -> a) -> r a -> m () i think you need the FD in both directions (certainly you need m -> r); i think the latter would serve to disambiguate things like readRef (having not actually implemented this, though, i don't know). - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
Hal Daume III writes: : | [1] i'm thinking of something like: | | class MonadRef m r | m -> r, r -> m where | newRef :: a -> m (r a) | readRef :: r a -> m a | writeRef :: r a -> a -> m () | updateRef :: (a -> a) -> r a -> m () This bears some resemblance to a lively thread back in February. Here's how it started: http://haskell.cs.yale.edu/pipermail/haskell/2002-February/008842.html
Ah yes, I now remember this thread. (How could I forget John's emphatic "No, no, no!"s? There doesn't seem to be any resolution to it, though, at least in the archives. It seemed mostly to be a conversation between John and Ashley, with Simon chiming in once in a while. As best I can tell, the final state of the discussion was: Simon: proposes having two RefMonads, one with only two instance (for IO and for ST) and one with user-definable instances. Definately wants some sort of generalization. Also proposes the "Ref IO a"/"Ref (ST s) a" dichotemy. John: Wants the RefMonad with the fun dep because it's more general than Simon's; primarily because users cannot write new instances of Simon's RefMonad (the only two instances will be for IO and ST and these will be built in). DOesn't like Simon's dichotemy because it breaks existing code with explicit type sigs. Ashley: Proposes: data Ref m a = MkRef { get :: m a, set :: a -> m () } class RefMonad m where { newRef :: a -> m (Ref m a) } wants to ensure (like John) that it is easy to move these things across lifted monads. Did anything ever get resolved about this? A quick and dirty grep through the documentation doesn't turn up any RefMonad stuff. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 19 Sep 2002, Tom Pledger wrote:
Hal Daume III writes: : | [1] i'm thinking of something like: | | class MonadRef m r | m -> r, r -> m where | newRef :: a -> m (r a) | readRef :: r a -> m a | writeRef :: r a -> a -> m () | updateRef :: (a -> a) -> r a -> m ()
This bears some resemblance to a lively thread back in February. Here's how it started:
http://haskell.cs.yale.edu/pipermail/haskell/2002-February/008842.html _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (2)
-
Hal Daume III -
Tom Pledger