Hacker News new | past | comments | ask | show | jobs | submit login

I looked that up in my copy of "Parallel and Concurrent Programming in Haskell" by Simon Marlow, and indeed you're right -- the runPar function shouldn't let you return an IVar, but it does. This is planned to be "fixed in a future release", but the current online documents say about the same thing.

Presumably, this could be fixed easily by using the phantom type trick (same as ST) but it would make the type signatures ugly and possibly break existing code. (Maybe there's a more modern alternative to phantom types?) So, yeah, you might not want to use the Par monad as it's currently implemented in ghc as your secure parallel sandbox.

The online docs suggest using lvish if you want a safer Par monad interface, which I'm not familiar with (though the lvish docs say that it's not referentially transparent if you cheat and use Eq or Ord instances that lie).

The general idea seems sound, though -- it should be possible to have parallelism in a sandbox environment without allowing the sandboxed program to conditionally execute code based on which of several threads finished some task first.

I point isn't that it is impossible in theory. It is just that, in practice, we do not have a good track record of locking down pre existing languages. As much as Haskell is one of the more idealogically pure languages, its ecosystem is still written under the general assumption that its programmers are not malicious geniuses.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact