Bulat Ziganshin wrote:

Hello Gracjan,

Tuesday, June 07, 2005, 2:25:50 PM, you wrote: class Monad m =>> Ref m r | m -> r where GP> newRef :: a -> m (r a) GP> readRef :: r a -> m a GP> writeRef :: r a -> a -> m ()

may be the following will be even more interesting:

I like it very much!

import Control.Monad import Data.IORef

infixl 0 =:, +=, -=, =::, <<= ref = newIORef val = readIORef a=:b = writeIORef a b

Pretty shame := is already reserver :(. There is something alike Graphics.Rendering.OpenGL.GL.StateVar. The use $= for assignment. Generalizing "variables" (in respect to some monad) seems to be often reinvented idea :) As I see this could be generalized to all Ref-like constructs (IO,ST,others?)

a+=b = modifyIORef a (\a-> a+b) a-=b = modifyIORef a (\a-> a-b) a=::b = ((a=:).b) =<< val a Is this convoluted modify? Why doesn't it use modifyIORef? Or am I wrong?

for :: [a] -> (a -> IO b) -> IO () for = flip mapM_

I like: foreach = flip mapM foreach_ = flip mapM_

newList = ref [] list <<= x = list =:: (++[x])

Is this append?

push list x = list =:: (x:) pop list = do x:xs<-val list; list=:xs; return x

main = do sum <- ref 0 lasti <- ref undefined for [1..5] $ \i -> do sum += i lasti =: i sum =:: (\sum-> 2*sum+1) print =<< val sum print =<< val lasti

xs <- newList for [1..3] (push xs) xs <<= 10 xs <<= 20 print =<< val xs

Haskell as ultimate imperative language :)

I use this module to simplify working with references in my program. The first inteface can be used for IORef/STRef/MVar/TVar and second for lists and Chan

Then we should create classes for those interfaces. -- Gracjan

On 6/8/05, Gracjan Polak wrote:

Tomasz Zielonka wrote:

...

On Tue, Jun 07, 2005 at 12:25:50PM +0200, Gracjan Polak wrote:

To put it another way: is Data.Map only workaround to get something done, or is it The Right Way of doing PQs in Haskell?

Another option is to look at Chris Okasaki's _Purely_Functional_Data_Structures_ (code available at his website). Pairing heaps and splay heaps (when bootstrapped) are said to have O(1) in everything but removeMin (new, insert, merge, findMin) and good constant factors. Colin DeVilbiss

Gracjan Polak writes:

To put it another way: is Data.Map only workaround to get something done, or is it The Right Way of doing PQs in Haskell?

Another option is the priority queues from the Rabhi & Lapalme book: http://www.iro.umontreal.ca/~lapalme/Algorithms-functional.html -- It seems I've been living two lives. One life is a self-employed web developer In the other life, I'm shapr, functional programmer. | www.ScannedInAvian.com One of these lives has futures (and subcontinuations!)| --Shae Matijs Erisson

Sven Panne writes: | ajb@spamcop.net wrote: | > Quoting Gracjan Polak : | > [...] | >>Is there any reason why isn't it included? | > | > | > Nobody could agree on the details. For example, MVars are | > perfectly respectable Refs on the IO monad. So would it make sense | > to add an instance for that? If so, the functional dependency | > should go, which introduces its own problems. | | A few more design problems: | | * Due to the functional dependency, that class is not Haskell98, | which is a *very* good reason IMHO not to standardize it, at least | in that way. Remember: There are not only GHC and Hugs out | there... | | * The 3 operations should not be packed together in a single class, | because there might be e.g. references which you can't create | (e.g. OpenGL's state variables), references which are read-only > | and even references which are write-only. | | * What about strictness of e.g. the setter? There is no "right" | version, this depends on the intended usage. | | * Are the references located in the monad (like in the suggested | class) or are they within objects, which have to be given as | additional arguments (e.g. like wxHaskell's widgets/Attr/Prop). | | * Atomic operations might be needed, too. These are all good points, but while it's fair to say that a MonadRef class is wrong for some situations, I don't think it's wrong for all situations. It isn't Haskell98, but neither is the ST monad or practically anything else in Control.Monad.*. Regarding strictness vs. non-strictness, I would say leave it up to the specific monad. I think the best way to look at MonadRef is as a generalization of MonadState. Consider:

{-# OPTIONS -fglasgow-exts #-}

import Control.Monad.Reader import Control.Monad.State import Control.Monad.ST import Data.STRef

class Monad m => MonadRef r m | m -> r where newRef :: a -> m (r a) readRef :: r a -> m a writeRef :: r a -> a -> m ()

instance MonadRef (STRef r) (ST r) where newRef = newSTRef readRef = readSTRef writeRef = writeSTRef

instance MonadRef r m => MonadRef r (ReaderT e m) where newRef = lift . newRef readRef = lift . readRef writeRef = (lift.) . writeRef

newtype RefToState r s m a = RTS (ReaderT (r s) m a) deriving (Functor, Monad)

instance MonadRef r m => MonadState s (RefToState r s m) where get = RTS (ask >>= readRef) put s = RTS (ask >>= \r -> writeRef r s)

evalRefToState :: MonadRef r m => RefToState r s m a -> s -> m a evalRefToState (RTS m) s0 = newRef s0 >>= runReaderT m

runRefToState :: MonadRef r m => RefToState r s m a -> s -> m (a, s) runRefToState (RTS m) s0 = do r <- newRef s0 x <- runReaderT m r s <- readRef r return (x,s) -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"