Whoops! Thanks for pointing that out. I'll fix it and push new docs.
There's not much magic in that part of the code itself; the nasty magic is
knowing that the first pointer in any record is in the same position in its
heap object as the first component of a pair. Speaking of which, do you
have any idea if it'll work for non-record types whose constructors all
have the same first field? I'm guessing yes, but I haven't experimented yet.
On Fri, Mar 10, 2023, 3:27 AM Tom Smeding
Hi David,
Fancy stuffs!
Wondering how much magic was going on in implementing this, I saw that atomicModifyIORef2Native misses the haddock marker '|' in the source; thus your extensive doc comment doesn't show up on hackage.
Cheers, Tom
On 10/03/2023 03:01, David Feuer wrote:
I just put together a new package, atomic-modify-general, for generalizations of the `atomicModifyIORef` operation. In particular:
1. Versions that allow a result of an arbitrary type (not necessarily a pair), where the caller passes in an extraction function. These work with `Array` and `SmallArray` from `primitive` as well as `IORef`. 2. A version that works with record types (not just pairs) whose first field is the new value to install in the `IORef`. This uses implementation details of the `atomicModifyMutVar#` primop as well as GHC's heap object layout to achieve better performance.
Please try it out and let me know how it goes, and what extras you may want!
Hackage: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0 _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.