On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy <[email protected]>wrote:
> On 25/01/2011, at 22:05, Daniel Peebles wrote: > > > 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 > > You don't have to know that. If you pass a ByteArray# to a foreign call, > the function you are calling gets a pointer to the actual data. That said, > I'm all for providing these operations somewhere in base, I just don't think > they have to be primops. Hmm, I guess we'll have to wait for Simon to weigh in on that then! > > b) the card marking stuff for Array#, both of which could easily change > between GHC versions. > > Oh, I'm not arguing against the Array# versions at all. > > Hmm, come to think of it, could they perhaps be written in Cmm (calling > memcpy etc. internally) and imported using the (rather obscure) "prim" > calling convention? > > > http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/ffi.html#ffi-prim > > They wouldn't have to be true primops then, i.e., they wouldn't require > extensions to the compiler itself. I don't know if this is feasible, though. I considered that actually, but they seemed of general-enough interest that I think it'd make sense for them to be primops. Duncan Coutts has mentioned that foreign import prim wasn't really meant for average library code. I'm actually using the prim foreign calls in a binding to GMP naturals I've been writing, and it seems to work fine, but from what I understand from IRC, the GHC people don't really mind the idea of these primops going in as actual primops. I guess we'll have to wait and see :) There's also talk of switching the Primops.cmm imports from the .pp file to an actual set of foreign import prim declarations, which would allow real haddock! Not sure what to do about the inline primops though! Thanks, Dan
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
