2 ms·
I don't feel like the post was being dismissive. The key sentence is toward the beginning: "The genius of the compiler created for the paper is how it offers s
by bunderbunder 14y ago
I don't feel like the post was being dismissive. The key sentence is toward the beginning: "The genius of the compiler created for the paper is how it offers safety and allows auto-threading with much less effort than previous attempts."
For example, I'm not terribly skilled in Haskell but I believe the ST monad has to be managed manually by the programmer. You do get a pocket of mutability that allows you to constrain state to a particular scope, but that pocket has to be manually defined by the programmer, and internal to that state the programmer's still responsible for ensuring that any concurrency relating to the mutable data is handled in a thread-safe manner.
As far as freezing/thawing, again I'm no expert but I believe it doesn't work quite the same way as what's being described in the paper. Freezing an array in Haskell doesn't involve taking an existing array and declaring that its contents can no longer be modified; instead the freeze operation creates and returns an immutable copy of the array. (Same for thaw.) There are also unsafeFreeze and unsafeThaw which don't do that, but they really are unsafe. The unsafeFreeze operation doesn't take away your MArray, and that MArray happens to be pointing to the same storage as the Array. Unless there's something else going on in there I don't know about, that's a situation for which the word 'unsafe' is an understatement.
Perhaps there are other facilities in Haskell I don't understand which are able to do what this C# extension does, and not just doing different things that happen to be describable using similar language. If so I'd be really interested to see them. And really curious to know why there hasn't been more interest in them thus far.