[Haskell-cafe] unboxed arrays restricted to simple types (Int, Float, ..)

[Hemanth Kapila]

On Wed, Nov 11, 2009 at 5:28 PM, Tillmann Vogt <Tillmann.Vogt at rwth-aachen.de
> wrote:

> Hi,
>
> I tried to use unboxed arrays for generating an antialiased texture. To
> make it easier to understand, here is the stripped down code that produces
> an error:
>
> >import Control.Monad.ST
> >import Data.Array.ST
> >import Data.Array.Unboxed
> >import Data.Word
> >type BitMask = UArray Int Word16 -- for determining the grey value of a
> pixel
> >type Pixels = (Int, Int, T)
> >data T = N | B BitMask -- this does not work
> >-- type T = Int -- this works if int the next line N is replaced by ..lets
> say 0
> >f = newArray (0,10) N :: (ST s (STUArray s Int T))
>
>
> http://hackage.haskell.org/packages/archive/array/0.2.0.0/doc/html/Data-Array-MArray.html#t%3AMArray
> shows that mutable/unboxed arrays only allow simple types:
> i.e.  MArray (STUArray s) Int32 (ST s)
>
> Isn't this ugly? Imagine this would be the case in C:
>
>
> struct stupidArrayElement{
>  int a;
>  int b; // not allowed!
> }
>
> stupidArrayElement s[10];
>
>
> Wouldn't it be nice to have something like: MArray (STUArray s) e (ST s)
> with e being a non-recursive data type (like data T = N | B Bitmask).
> My understanding of Haskell isn't deep enough to know if I have overlooked
> something or if the problem is solvable without a language extension. With a
> language extension I guess that it is not hard to find out if an abstract
> data type is non-recursive. Then this type should be serializable
> automatically.
>
> What do you think?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Actually, there's a cool package called  storable record. Could it be of
some use to you? (Perhaps you *might* be able to use it if the BitMasks  are
of uniform length). Am not 100% sure though.

Isn't this ugly?

I am not sure if it is really *ugly*...    and if am allowed to nit-pick,
the analogy with C  is not appropriate either.
Arrays are just different.  (At least thats how I console myself, when am
looking for a high performance strict array). Also, on an approximately
related issue,
 I was suggested to look into data parallel arrays.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091111/56171acc/attachment.html