[Haskell-cafe] Mutable arrays

Jeff φ jeff1.61803 at gmail.com
Wed Feb 6 17:31:59 EST 2008


On 2/6/08, Chaddaï Fouché <chaddai.fouche at gmail.com> wrote:
>
> 2008/2/6, Jeff φ <jeff1.61803 at gmail.com>:
> > I have solved both of these problems in Clean using a lazy list without
> > resorting to unsafe operations.  So, it seems to me that uniqueness
> types
> > are more general than monads.
>
> Are you aware that your code in Clean has some issues, like the lst
> not being so lazy if you operate on ary2 before you operate on lst (it
> is completely put in memory in this case) ? You've effectively created
> a big uncertainty on the space taken by your function. Is this ok with
> you ?


Yes, I'm aware of this.  In a previous post, I wrote, "I should mention
that a problem with the code I've shown is that it is very sensitive to the
order in which the expression graph is evaluated.  Simple changes can cause
lst to become strict and the program to run out of heap."  However, I think
your description of this issue is much more succinct than mine.

I'm not sure, but I _think_ this problem can be solved using Clean's strict
let-before notation.

normalize_2D_ary ary =
    #  (lst,ary) = uToList_2D ary
    #! max_elem = foldl1 max lst // max_elem is strict -- lst is consumed.
    =  map_in_place_2d_arr (\ x -> x / max_elem) ary


>  The monadic fold (like I and some others proposed) guarantee you
> a constant amount of memory consumed and is perfectly safe too, is the
> Clean solution really so much better ?
>

I'm looking forward to spending a few free hours this weekend playing
with the monadic fold code.  I've written a lot of image processing code in
Clean that treats images as lists of RGBA tuples.  It's a very
useful abstraction.  But, I've spent more time than I care to admit
fixing unexpected stack and heap overflows that were caused by seemingly
unrelated code change.  I hope to find other abstractions that aren't so
fragile.

Peter Verswyvelen <bf3 at telenet.be> wrote:

> Now from the little time I've spent in the company of Clean, I must say
> there's another advantage of uniqueness typing: it is very easy to
> understand. While monads are a tiny bit more demanding! But monads give such
> a mental satisfaction once you see the light  ;-)
>

For me, the light is a faint distant flicker.  I hope to see it clearer
someday.

At the risk of starting a flame war, being labeled a troll, having Godwin's
law invoked, and suffering a life time ban from Haskell-Cafe, I'd like to
broach another subject.  I noticed that GHC implements mutable arrays in the
IO monad.  This seems odd to me.  Arrays aren't related to IO.  Are there
obstacles to mixing code that uses IO monads and array monads that are most
easily worked around by sticking mutable arrays into the IO monad?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/8adbdfc4/attachment.htm


More information about the Haskell-Cafe mailing list