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.