[Haskell-cafe] What's the deal with Clean?

brian briand at aracnet.com
Tue Nov 3 21:12:29 EST 2009


Really, arrays in Haskell are the most @#!$! confusing thing in the  
world.

There's a bunch of different array structures.

I can't tell which one works best, and all I want to do is x[i] = value.

I thought uvector was the answer, you know, fast unboxed ARRAYs.   
Imagine my surprise when I saw this

   indexU :: UA e => UArr e -> Int -> e

   O(n). indexU extracts an element out of an immutable unboxed array.

An array implementation with an order N lookup.  huh ??  That's not an  
array, that's a list.  I was looking for an array.

However, I then found in the same hackage:

   readMU :: MUArr e s -> Int -> ST s e

   O(1). readMU reads the element at the specified index of a mutable  
unboxed array.

So O(1) for mutable, but O(n) for immutable ? See, confusing...  I'm  
sure there's a really good, lofty type safety, something
or other reason for that, that I'm sure I don't care about ;-)

There's also ST.  So why is there a uvector, when there's ST ??

etc, etc, etc...

and then there's monads...

other than that, having fun with haskell :-)

Brian


On Nov 3, 2009, at 3:42 PM, David Leimbach wrote:

>
>
> On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh <tracy.wadleigh at gmail.com 
> > wrote:
>
> I had to implement a ring buffer, and I wanted the code using it to  
> be written in Haskell.  I ended up implementing the buffer in C, and  
> wrapping it in FFI from Haskell because implementing a destructive  
> array in Haskell is kind of unwieldy to someone of my experience  
> level.  In Clean, it looks like the uniqueness typing allows for  
> destructive updates in a very controlled manner.
>
> The ST monad provides this functionality. The never-instantiated-in- 
> a-visible-way state parameter of the ST monad provides the  
> "uniqueness" required for doing destructive updates in a pure way.
>
> Someone suggested that to me on IRC once I'd already cranked out a C  
> implementation with FFI bindings.  It's just too easy to use the FFI  
> in Haskell :-)
>
> If we raise the barrier of FFI, more people will use ST!
>
> Dave
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list