Hi all, I'm trying to figure out how to use STUArray. Is it possible to let it be polymorphic? Here is an excerpt from my program: class (IArray UArray k, Ord k, Fractional k) => Elt k class (Bounded a, Enum a, Ix a, Eq a, Show a) => IxB a -- |like Array but uses IxB instead of Ix newtype Vector k i = Vector (UArray.UArray i k) deriving (Eq) margin :: (IxB a, IxB b, Elt k, (MArray (STUArray s) k (ST s))) => Vector k a -> (a -> b) -> Vector k b margin (Vector v) f = Vector (runSTUArray (do ax <- newArray (minBound, maxBound) 0 mapM_ (\ (i,x) -> updateArray ax (f i) (+x)) (assocs v) return ax )) where updateArray ax i f = do e <- readArray ax i writeArray ax i (f e) When I try to run it, I get the following error. I think I understand what the error means, but not how to fix the problem: Vector2.hs:166:22: No instance for (MArray (STUArray s) k (ST s)) arising from use of `updateArray' at Vector2.hs:166:22-32 Probable fix: add (MArray (STUArray s) k (ST s)) to the expected type of an expression or add an instance declaration for (MArray (STUArray s) k (ST s)) In a lambda abstraction: \ (i, x) -> updateArray ax (f i) ((+ x)) In the first argument of `mapM_', namely `(\ (i, x) -> updateArray ax (f i) ((+ x)))' In a 'do' expression: mapM_ (\ (i, x) -> updateArray ax (f i) ((+ x))) (assocs v) Thanks in advance, Frederik -- http://ofb.net/~frederik/
On Friday 10 March 2006 23:01, Frederik Eaton wrote:
I'm trying to figure out how to use STUArray. Is it possible to let it be polymorphic?
Hi Frederik I think this thread (and the one it referres to) provide a solution: http://www.mail-archive.com/haskell%40haskell.org/msg17081.html Ben -- There are three kinds of programmers: those who make off by one errors, and those who don't.
Hello Benjamin, Saturday, March 11, 2006, 1:49:10 AM, you wrote: BF> http://www.mail-archive.com/haskell%40haskell.org/msg17081.html to be exact, i implemented Oleg's idea and published this in Feb in haskell list. now i work on integrating this code with the Data.Array.* library -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
I see. The solutions on that thread, i.e.: http://www.mail-archive.com/haskell%40haskell.org/msg17085.html would seem to require me to at least declare an instance of some class, for every type that I want to support. So the short answer to "I'm trying to figure out how to use STUArray. Is it possible to let it be polymorphic?" appears to be "No". Perhaps some sort of warning in the documentation for STUArray is in order, until Bulat's code can be incorporated? By the way, why make the distinction between unboxable types and "other" types in the first place? E.g., just because I want something to work quickly on "Int", doesn't mean that I don't want it to work at all on "String". It seems that there could be a default "IArray UArray e" instance which just implements a regular Array behind the scenes. Frederik On Fri, Mar 10, 2006 at 11:49:10PM +0100, Benjamin Franksen wrote:
On Friday 10 March 2006 23:01, Frederik Eaton wrote:
I'm trying to figure out how to use STUArray. Is it possible to let it be polymorphic?
Hi Frederik
I think this thread (and the one it referres to) provide a solution:
http://www.mail-archive.com/haskell%40haskell.org/msg17081.html
Ben -- There are three kinds of programmers: those who make off by one errors, and those who don't. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Frederik, Sunday, March 12, 2006, 5:58:42 AM, you wrote: FE> Perhaps some sort of warning in the documentation for STUArray is in FE> order, until Bulat's code can be incorporated? excellent idea. you can make diff for Data.Array.ST/IO and send it to the libs maillist FE> By the way, why make the distinction between unboxable types and FE> "other" types in the first place? E.g., just because I want something FE> to work quickly on "Int", doesn't mean that I don't want it to work at FE> all on "String". It seems that there could be a default "IArray UArray FE> e" instance which just implements a regular Array behind the scenes. you can do it yourself. basically, unboxed arrays implemented in different way and has different (strict) semantics. btw, if you use only ghc, it's better to use parallel arrays (ghc.parr module) to work faster with arrays of non-unboxable types. i plan to provide hugs+ghc-compatible interface to this module as "strict arrays" implementation -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Frederik,
Sunday, March 12, 2006, 5:58:42 AM, you wrote:
FE> Perhaps some sort of warning in the documentation for STUArray is in FE> order, until Bulat's code can be incorporated?
excellent idea. you can make diff for Data.Array.ST/IO and send it to the libs maillist
FE> By the way, why make the distinction between unboxable types and FE> "other" types in the first place? E.g., just because I want something FE> to work quickly on "Int", doesn't mean that I don't want it to work at FE> all on "String". It seems that there could be a default "IArray UArray FE> e" instance which just implements a regular Array behind the scenes.
you can do it yourself. basically, unboxed arrays implemented in different way and has different (strict) semantics. btw, if you use only ghc, it's better to use parallel arrays (ghc.parr module) to work faster with arrays of non-unboxable types. i plan to provide hugs+ghc-compatible interface to this module as "strict arrays" implementation
Is GHC.PArr documented? The -fparr option is not in the 6.4.1 User's Guide. It seems that the source is at http://darcs.haskell.org/packages/base/GHC/PArr.hs
Hello Chris, Sunday, March 12, 2006, 2:05:09 PM, you wrote: CK> Is GHC.PArr documented? it's perfectly documented in module sources itself :) you can also look at the ndpFlatten directory in ghc compiler's sources. i've successfully used them in my program, of course this makes program faster but only-GHC compatible. so i plan to document it on http://haskell.org/haskellwiki/Arrays and incorporate it in Data.Array.* infrastructure so that strict arrays will be emulated under Hugs. CK> The -fparr option is not in the 6.4.1 User's Guide. they just forgot to do this :) btw, strict arrays will be a good candidate for Haskell-prime library standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin:
Hello Chris,
Sunday, March 12, 2006, 2:05:09 PM, you wrote:
CK> Is GHC.PArr documented?
it's perfectly documented in module sources itself :) you can also look at the ndpFlatten directory in ghc compiler's sources. i've successfully used them in my program, of course this makes program faster but only-GHC compatible. so i plan to document it on http://haskell.org/haskellwiki/Arrays and incorporate it in Data.Array.* infrastructure so that strict arrays will be emulated under Hugs.
CK> The -fparr option is not in the 6.4.1 User's Guide.
they just forgot to do this :) btw, strict arrays will be a good candidate for Haskell-prime library standard
No, it's not an oversight. The implementation is not complete. Just last week, we have started a second go at a complete implementation of fast arrays. Don't hold your breath though, it's a lot of work. The interface of GHC.PArr will not change very much, but it'll use type classes and associated types in a very essential way. Underneath, a lot of GHC specific will be used to optimise code, such as rewrite rules. So, I don't think this is suitable for Haskell'. Manuel
participants (5)
-
Benjamin Franksen -
Bulat Ziganshin -
Chris Kuklewicz -
Frederik Eaton -
Manuel M T Chakravarty