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.
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.