Bulat Ziganshin wrote:
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
Sure, but you're restricted to one kind of Var per monad. With MArray,
we have several array types per monad, and we could also have several
monads per array type - if, say, you wanted to implement an instance of
MArray for IOArray in your own IO-based monad, that's possible. Fewer
fundeps = more flexibility but more type annotations.
If we were to have overloaded references in the standard libraries, it
would look strange if the interface wasn't consistent with overloaded
arrays. I think you could mitigate the problem by providing
non-overloaded newIORef/newSTRef operations.
I'd support providing IOURef & STURef types, with overloading similar to
MArray (MRef).
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
The problem with doing this is you need a pretty beefy strictness
analyser to be able to tell whether the reference is being used
strictly, this is far beyond what GHC does (I'm impressed that jhc can
do this, but I don't think there's much hope for us doing it in GHC).
Better is for the user to request strict references, and have the
implementation do the unboxing, which is exactly what happens with
IOUArray. Furthermore, it's deterministic: if you ask for an IOUArray
(or IOURef), you're guarnanteed to get unboxing, which is better than
relying on some complex optimisation to work properly.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
