> Some commented type signatures in MArray interface mention ST instead
> of the generic monad. Signatures of MArray class operations have
> "a s ix e" instead of "a ix e".
Oh, thanks. As you can see, I've been through a few iterations with the
design already :)
> A proposal to resolve name clashes between IArray and MArray: suffix
> mutable with M, like currently mapM, zipWithM, filterM etc. It's not
> clear if M would come from *M*onad or from *M*utable.
I was hoping that the module system might help out here: ie. MArray.assoc
vs. IArray.assoc etc., but it might turn out that this is just too painful.
Your proposal is noted.
> For consistency references could be overloaded wrt. the monad too.
> It leads to a conflict among generic names for arrays and references:
> read and write.
agreed, I was going to try this too.
> Why do ArrayBase.newUArray and fill use foldr instead of mapM_?
> Does GHC generate worse code for mapM_ (which would be a pity itself)?
For foldr/build fusion: eg. (array ixs . map) is supposed to fuse.
I've still to do some proper experiments to check that all this abstraction
can be properly optimised away, and that includes making sure that fusion
works too. Initial tests seem fairly positive though.
> It looks like complexity of IArray.accumArray is O(n^2).
Yep, I haven't bothered importing GHC's efficient version yet.
Thanks for the comments,
Simon
