
On 2/6/08, Chaddaï Fouché
2008/2/6, Jeff φ
: 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
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?