Oh, and obviously it could replace newArray#, which would just be using (\_ -> k) as the function. Is the optimization machinery clever enough to see the constant function on a primop boundary and fold it in?
On Sat, Jan 29, 2011 at 7:42 PM, Daniel Peebles <[email protected]>wrote: > 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
