RE: Reference types

At 2002-02-07 02:09, I wrote: >The kind of generalisation you are proposing is, in my opinion, best done >explicitly by Haskell. Primitive functions and types should be as simple, >concrete and primitive as possible. Let Haskell do the clever >generalisation stuff. As a rule, I'm opposed to a

RE: Reference types

Simon writes: There were really two parts to my message: 1. Have a single built-in type (Ref), rather than two (IORef and STRef). I don't see how that can be anything other than a Good Thing, can it? The primitive operations over Refs are still non-overlo

RE: Reference types

At 2002-02-07 01:19, Simon Peyton-Jones wrote: >1. Have a single built-in type (Ref), rather than two (IORef and >STRef). >I don't see how that can be anything other than a Good Thing, can it? The problem is that your Ref type is primitive, which means users wouldn't be able to create their ow

RE: Reference types

Wow. One innocent message... | Oh no, please don't do this! I use the RefMonad class, but | *without* the dependency r -> m. Why not? Because I want to | manipulate (for example) STRefs in monads built on top of the | ST monad via monad transformers. So I use the same reference | type with *

Re: Reference types

At 2002-02-07 00:52, John Hughes wrote: >Hmm. Yes. But you still haven't addressed dropping references created in the >transformed monad back into the underlying one again. Oh that's easy: liftedNewSTRef :: (LiftedMonad (ST s) m) => a -> m (Ref (ST s) a); liftedNewSTRef = lift

Re: Reference types

I have a solution... data Ref m a = MkRef { get :: m a, set :: a -> m (), modify :: (a -> a) -> m () }; -- m somehow uses 'rep' internally class (Monad rep

Re: Reference types

At 2002-02-05 16:54, I wrote: >data Ref m a = MkRef >{ >get :: m a, >set :: a -> m (), >modify :: (a -> a) -> m () >}; Better, data Ref m a = MkRef { get :: m a, set :: a -> m () }; modify :: (Monad m) => Ref m

Re: Reference types

At 2002-02-06 03:38, John Hughes wrote: >Well, I'm still not convinced. A reference *value* can't have the type > > (LiftedMonad (ST s) m) => Ref m a Oh, yeah, you're right. I made a mistake here: newSTRef :: a -> Ref (ST s) a; newSTLiftedRef :: (LiftedMonad

Re: Reference types

Ashley Yakeley wrote: At 2002-02-06 01:09, John Hughes wrote: >No no no! This still makes the reference type depend on the monad type, which >means that I cannot manipulate the same reference in two different monads! Yes you can. Consider: -- m some

Re: Reference types

At 2002-02-06 00:54, Koen Claessen wrote: >You are completely right, of course I meant r -> m! Right. There's the equivalent of an r -> m dependency because m is a parameter in the Ref type constructor. But it doesn't matter, because you can create values of this type: myIntRef :: (MyMon

Re: Reference types

At 2002-02-06 01:09, John Hughes wrote: >No no no! This still makes the reference type depend on the monad type, which >means that I cannot manipulate the same reference in two different monads! Yes you can. Consider: -- m somehow uses 'rep' internally class (Monad rep, Monad m) => Lif

Re: Reference types

John Hughes despaired: | Oh no, please don't do this! I use the RefMonad class, | but *without* the dependency r -> m. Why not? Because | I want to manipulate (for example) STRefs in monads | built on top of the ST monad via monad transformers.

Re: Reference types

At 2002-02-06 00:33, Koen Claessen wrote: >Hm... this looks nice. With slight name changes this >becomes: Oh if you must. I decided that Refs were _so_ fundamental that anytime you get, set or modify anything it could probably be represented as a Ref, so the functions merit highly generic name

Re: Reference types

John Hughes despaired: | Oh no, please don't do this! I use the RefMonad class, | but *without* the dependency r -> m. Why not? Because | I want to manipulate (for example) STRefs in monads | built on top of the ST monad via monad transformers. | So I use the same reference type with *many d

Re: Reference types

At 2002-02-05 15:10, John Hughes wrote: >Oh no, please don't do this! I use the RefMonad class, but *without* the >dependency r -> m. Why not? Because I want to manipulate (for example) STRefs >in monads built on top of the ST monad via monad transformers. So I use the >same reference type with *

Re: Reference types

The basic bind operations etc are overloaded for IO and ST, but to overload the Ref operations one needs to add class RefMonad r m | r -> m, m -> r where newRef :: a -> m (r a) readRef :: r a -> m a writeRe

Re: Reference types

At 2002-02-05 07:50, Simon Peyton-Jones wrote: > data Ref m a-- References in monad m, values of type a etc. You might be interested in: data Ref m a

Re: Reference types

Hi Simon On Tue, 5 Feb 2002, Simon Peyton-Jones wrote: > 2. I'd be interested to know of any other examples you have of > *bi-directional* functional depenencies. The above simplification > nukes my only convincing example. (Usually one set of > type variables determines another,

RE: Reference types

Hi Simon, The one parameter scheme that you've described breaks down if you want to generalize further and allow something like: class RefMonad r m where new :: a -> m (r a) read :: r a -> m a write :: r a -> a -> m () instance RefMonad IORef IO where ... instance RefMonad

Re: Reference types

I applaud the simplification. Getting rid of multi parameter classes and functional dependencies is a Good Thing. Unfortunately I am worried about the extensibility of the new scheme. You replace two types, IORef a and STRef s a by a single type: > data Ref m a-- References in monad