-
Notifications
You must be signed in to change notification settings - Fork 29
Instances for IORef/TVar/MVar and other mutable containers #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sounds reasonable to me. |
Makes sense to me. Way down in the guts of STRef is basically a data box that carries around a reference to that MutVar#, and it delegates to the underlying MutVar# for its identity, etc. My guess/assumption is that it is always strict, warranting the # kind, but it might be worth double checking with someone who can give a more authoritative answer, e.g. Simon Marlow. |
Yes, it is always strict. These built-in types are unlifted (meaning they cannot be |
Thanks. That'll help simplify the code I have for forcing all the way down to them in my not-yet-released Longer verson: In my case I have a Previously I was walking all the way down to the MutVar#, but if I can stop at the STRef constructor in the forcing pass it'll save a little bit of work. Fritz Henglein wrote a couple of papers on this idea (among others) in a more general setting. |
The above commit doesn't add the TVar instance because I wasn't able to import GHC.Conc safely. Is there a safe way to get this instance? Does the module need to become Trustworthy? |
@glguy tbh, I don't like to sacrifice maybe we could just have the maybe at some point in the future |
I'd like to propose the following instances:
I think forcing a mutable container should not force the contained value, since that is not really "part" of the data type, it is just referenced. The instances are nevertheless useful when working with APIs that expect NFData types, for example criterion.
The text was updated successfully, but these errors were encountered: