Hello Simon, Monday, February 06, 2006, 4:41:50 PM, you wrote: SM> The Var class is interesting - basically the equivalent of the MArray SM> class for mutable variables. Is there a reason you couldn't use the SM> same pattern as the MArray class? MArray of Ptr works fine, but for SM> some reason you couldn't do it with Var, why not? quick answer: because it don't use fundeps: class (HasBounds a, Monad m) => MArray a e m where vs class (Monad m) => Var m r a | r->a, m a->r where and fundeps used to avoid needing to specify type of created reference, as should be done with arrays: main = do arr <- newArray (1,10) 37 :: IO (IOArray Int Int) main = print $ runST (do arr <- newArray (1,10) 127 :: ST s (STArray s Int Int) while in my library one can write the following code: chars <- newVar (0::Int) inWord <- newVar False that will work in ANY monad (at least ST and IO with current Var instances). btw, Ptrs is not very useful outside of IO monad (although they can be very useful for extended-IO sort of monads) i will check this more thoroughly SM> I suggest you follow the same scheme as the unboxed array types, and SM> have IOURef/STURef types, parameterised over the element type. Of SM> course, we should have instances for all of the primitive numeric types SM> plus Ptr, ForeignPtr, StablePtr, Bool. i think that i should implement this and add my own Var class as the user of this more general library, that serves my own purpose of writing monad-independent code btw, i have the counter proposal - automatically convert IORefs of simple types to the fast internal variables like the Int automatically converted to the Int#. The same applies to automatic conversion of arrays to the unboxed arrays -- Best regards, Bulat mailto:bulatz@HotPOP.com