4 ms·

This article's author seems to be very dismissive of Haskell. Which is a little odd because, at least as described in the article (I haven't had time to look at

by tikhonj 14y ago

This article's author seems to be very dismissive of Haskell. Which is a little odd because, at least as described in the article (I haven't had time to look at the paper yet), the approach taken by this compiler is actually very similar to what is already done in Haskell. In particular, Haskell already supports initializing data structures mutably and then "freezing" them. I know this technique is used in the Vector library, for example. Additionally, "pockets of imperative mutability" perfectly describes Haskell's "State Threads" (ST). Programming in Haskell already allows you to have arbitrary state constrained to a particular scope and controlled by the type system. Using things like ST with immutability by default is just tracking state in the type system. And--as long as you don't worry about how it's implemented under the hood--ST isn't terribly difficult to use. I'm sure the auto-threading compiler is very novel and interesting research, and I'm sure it's very useful. However, I think that you shouldn't be this dismissive of Haskell, especially because Haskell already does essentially everything described in the article.

DanWaterworth 14y ago
I agree with this. The article also contains this excerpt: Even though there are significant benefits to programming with immutability, programming without state is also tricky and usually requires workarounds in FP. 'Workarounds' links to a page that describe Haskell's state monad, but Haskell's state monad only uses immutable state. It's just a wrapper around an ordinary function with the type: (s -> (o, s)) . As far as workarounds go, this is not a good example.
bascule 14y ago
I think they're working on a language for mere mortals instead of FP wizards. Seems cool to me. I mean, you could respond to claims like: > This addresses problems under which functional programming (FP) labors, like creating cycles of immutable objects. ...that in Haskell we can create cyclical data structures using laziness via tying the knot. But uhh, wouldn't it just be a whole lot easier to build cyclical relationships using mutable state then freeze the whole thing? I guess what I'm saying is Haskell is hard, let's go shopping... for sufficiently smart compilers!
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.

by tikhonj 14y ago

DanWaterworth 14y ago

I agree with this. The article also contains this excerpt: Even though there are significant benefits to programming with immutability, programming without state is also tricky and usually requires workarounds in FP. 'Workarounds' links to a page that describe Haskell's state monad, but Haskell's state monad only uses immutable state. It's just a wrapper around an ordinary function with the type: (s -> (o, s)) . As far as workarounds go, this is not a good example.

bascule 14y ago

I think they're working on a language for mere mortals instead of FP wizards. Seems cool to me. I mean, you could respond to claims like: > This addresses problems under which functional programming (FP) labors, like creating cycles of immutable objects. ...that in Haskell we can create cyclical data structures using laziness via tying the knot. But uhh, wouldn't it just be a whole lot easier to build cyclical relationships using mutable state then freeze the whole thing? I guess what I'm saying is Haskell is hard, let's go shopping... for sufficiently smart compilers!

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.