On Tue, 2004-06-29 at 18:42, MR K P SCHUPKE wrote:
Erm, something I remember about needing MArrays... Here's something which does the same thing (cooks and MArray then freezes it - also using STUArray... The neat thing is MArray is a class, so you can swap between STUArray and STArray implementations without changing code.
I tried generalising the type to not mention which of STUArray and STArray I'm using. Letting ghc infer the type gives this type, unfortunately annotating the function with this type gives a type error!! Compiler/typechecker bug perhaps? buildUArray bounds f = do arr <- buildUArray' bounds f unsafeFreeze arr ghc infers this type: buildUArray :: forall a i b s array. (MArray (array s) a (ST s), Ix i, IArray b a) => (i, i) -> (i -> a) -> ST s (b i a) however if one add this annotation I get the same error message I got originally: Could not deduce (MArray (array1 s) a (ST s)) from the context (MArray (array s) a (ST s), Ix i, IArray b a) arising from use of `unsafeFreeze' at BuildArray.hs:25 Probable fix: Add (MArray (array1 s) a (ST s)) to the type signature(s) for `buildUArray' Or add an instance declaration for (MArray (array1 s) a (ST s)) In the result of a 'do' expression: unsafeFreeze arr In the definition of `buildUArray': buildUArray bounds f = do arr <- buildUArray' bounds f unsafeFreeze arr
This is the classic dynamic programming version of string difference:
[snip] The difference with your example cod is that I return the array itself rather than a value calculated using the array. With your code, as soon as we try to return the array too, I run into the same problem. Duncan