Arrays and arrays

[Ketil Z. Malde]

ketil@ii.uib.no (Ketil Z. Malde) writes:

> Hal Daume III <hdaume@ISI.EDU> writes:

>> Yes, (//) is terrible.  It *never* tries to update in-place.  

> Any reason it couldn't be done in-place?  (I.e. thaw, update all, and
> freeze again)  Am I missing something -- Could partial results be
> used, the update list be infinite, or anything like that?

I'm toying with STArrays in order to fix this.  In prinicple it should
be simple, but it ended up a tangled mess of incomprehensible warnings
and strange errors.  Oh well, I've boiled it down to something like:

  replace :: UArray Int Int -> [(Int,Int)] -> UArray Int Int
  replace a p = runST (thaw a >>= \u -> update u p >> freeze u)

  update :: STUArray () Int Int -> [(Int,Int)] -> ST () ()
  update u ps = mapM_ (uncurry (writeArray u)) ps

Which gives me

  Compiling SuffixArray      ( SuffixArray.lhs, interpreted )

  SuffixArray.lhs:131:
    Cannot unify the type-signature variable `s' with the type `()'
	Expected type: ST s a
	Inferred type: ST () (b Int Int)
    In the expression: (thaw a) >>= (\ u -> (update u p) >> (freeze u))
    In the first argument of `runST', namely
	`((thaw a) >>= (\ u -> (update u p) >> (freeze u)))'

I've tried rearranging the code in various ways, but I can get no
further. 

Sounds to me that setting s=() and a=(b Int Int) would do the trick,
but apparently the compiler disagrees.  I haven't used the ST monad
before, so perhaps I'm missing something obvious?

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants