In a slightly related proposal on the same topic, what do people think of: newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s, MutableArray# s a #)
that would do the obvious thing, by allocating an array of the size specified by the Int#, and then pass indices into the function to get elements. This would again be to avoid the initialization cost for large arrays, but provides a way more flexible interface than the clones (which could be implemented in terms of it, but not as quickly). On Tue, Jan 25, 2011 at 5:05 PM, Daniel Peebles <[email protected]>wrote: > So, to summarize what you guys have been talking about, it's looking like > the primops would become: > > copyArray# :: Array# a -> Int# -> MutableArray# s a -> Int# > -> Int# -> State# s -> State# s > copyMutableArray# :: MutableArray# a -> Int# -> MutableArray# s a -> Int# > -> Int# -> State# s -> State# s > > copyByteArray# :: ByteArray# -> Int# -> MutableByteArray# s > -> Int# -> Int# -> State# s -> State# s > copyMutableByteArray# :: MutableByteArray# s -> Int# -> MutableByteArray# s > -> Int# -> Int# -> State# s -> State# s > > > cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# > State# s, Array# a #) > cloneMutableArray# :: MutableArray# s a -> Int# -> Int# -> State# s -> (# > State# s, MutableArray# s a #) > > freezeArray# :: MutableArray# s a -> Int# -> Int# -> State# s -> (# State# > s, Array# a #) > thawArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# > s, MutableArray# s a #) > > Roman: I'm thinking that even in the absence of GC during foreign calls, it > still seems worthwhile to provide the plain copying primitives, if only to > save "user" code from having to know a) the structure of a (Byte)Array# and > where the "data" lives vs. the metadata b) the card marking stuff for > Array#, both of which could easily change between GHC versions. > > Does this seem reasonable? I was thinking of putting in the fillArray# > primitive you suggested too (and making it use memset_pattern on mac OS), > but then we'd need a bunch of different fillArray# for different-sized > things on ByteArray# and that might get ugly. I do however like the idea of > putting in a generic operation that may not be optimized on all platforms > right now, but will only get faster with time (once we come up with > memset_pattern analogues on other platforms). > > Thanks, > Dan > > On Tue, Jan 25, 2011 at 4:50 PM, Johan Tibell <[email protected]>wrote: > >> On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy <[email protected]> >> wrote: >> > thawArray# (which creates a mutable copy), update the element, then >> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory, >> since both unsafeFreeze# and unsafeThaw# do some work we might want 4 >> different variants of clone: >> > >> > Array# -> Array# >> > MutableArray# -> MutableArray# >> > MutableArray# -> Array# >> > Array# -> MutableArray# >> > >> > I just proposed to call the latter two thaw and freeze to avoid >> confusing names. I'm not sure if all of them are equally important, even >> though I would probably use all 4 in vector. >> >> I think I like this. The first version (Array# -> Array#) of close is >> only really usable if you want to make sure that an array occupies >> less memory than before, but I can see that being useful when slicing. >> >> Johan >> > >
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
