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 at HotPOP.com