Skip to content
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

ST monad trick #47

Open
mitchellwrosen opened this issue May 27, 2017 · 2 comments
Open

ST monad trick #47

mitchellwrosen opened this issue May 27, 2017 · 2 comments

Comments

@mitchellwrosen
Copy link

Hi, I was just re-reading your excellent book and came across this warning:

There is nothing in the types to stop you from returning an IVar from runPar and
passing it to another call of runPar. This is a Very Bad Idea; don’t do it. The 
implementation of the Par monad assumes that IVars are created and used 
within the same runPar, and breaking this assumption could lead to a runtime 
error, deadlock, or worse.

The library could prevent you from doing this using qualified types in the same
way that the ST monad prevents you from returning an STRef from runST. This 
is planned for a future version.

Just curious, is this still meant to happen at some point?

@simonmar
Copy link
Owner

I'm not actively working on monad-par, so I doubt this will happen, unless someone else really wants to work on it. It would be a big breaking change for existing users, which could be a problem. I think I was also worried about the extra type clutter this would cause, for limited benefit, but I probably wouldn't object very strongly if someone else were doing the work to push this through.

@treeowl
Copy link
Contributor

treeowl commented Jun 19, 2018

One option would be to offer extra modules exposing the safer versions. That's a bit of extra clutter on Hackage, but maybe it would be worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants