major missing piece to arrays?

John Meacham john at repetae.net
Mon Jul 19 21:23:21 EDT 2004


On Tue, Jul 20, 2004 at 02:56:15AM +0200, Carsten Schultz wrote:
> On Thu, Jul 15, 2004 at 04:26:27AM -0700, John Meacham wrote:
> > I am thinking a family of routines. (with psuedosignatures)
> > 
> > copySpan: range -> MArray -> whereto -> MArray -> m ()
> > extractSpan : range -> IArray -> IArray
> > extractSpanM : range -> MArray -> m IArray
> > saveSpan : range -> IArray -> whereto -> MArray -> m ()
> 
> I would like to have these, too.  I would especially like to have
> 
>     saveSpan :: (Int, Int) -> UArray Int Word8 -> (Int, Int)
>                   -> IOUArray Int Word8 -> IO () 
>     copySpan :: (Int, Int) -> IOUArray Int Word8 -> (Int, Int)
>                   -> IOUArray Int Word8 -> IO ()
> 
> to use these in conjunction with hGetArray and hPutArray.
> 
> In the hope of advancing the discussion, I have taken up the trivial
> task of implementing the above on top of the usual array functions.
> (I have not done any testing, though.)  Maybe some kind soul with
> knowledge of the ghc innards can provide an implementation that
> reduces to a memcpy call, at least for some specializations.

Cool, I can build more efficient versions on these now that I know the
ByteArray# as Addr# trick. 

I am curious what the best way to go about writing specialized versions
is, 
placing the copying functions in a class, with (slow) default methods
for everything and special instances for (IO)UArrays? or relying on
RULES pragmas to do the appropriate specialization? 

anyone have any intuition on which would be a better approach to take?
The class is more straightforward, but since we are not changing
behavior, just doing a pure type based optimization, perhaps RULES is
the better way to go. 

(can RULES even be used in this way? it looks like they are already to
implement unsafeFreeze and unsafeThaw)

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈ 


More information about the Libraries mailing list