3 ms·
> That's a pretty big "except" - there are no side effects except for all the side effects (and there's nothing unique about JavaScript there, that much is the
by tinco 5y ago
> That's a pretty big "except" - there are no side effects except for all the side effects (and there's nothing unique about JavaScript there, that much is the same as almost any other language)
It's not like Haskell doesn't have those either though, I don't think it's a very big except. Discussing synchronous I/O in JavaScript is not interesting, were not littering our Haskell with unsafePerformIO either.
> JavaScript's approach to I/O, like most languages, uses things that look like functions but aren't functions, in that they give different outputs for the same inputs.
No, this is just not true, are we using the same JavaScript? JavaScript's functions change only based on modified application state, not on any other side effect.
> The whole point of Haskell's I/O system, the thing that separates it from other languages, is that it doesn't do that; in Haskell your functions are actually functions and I/O operations are very clearly not functions.
Sure, in the current Haskell that's true. In previous iterations of Haskell this wasn't always the case though, monadic I/O wasn't the first pure system, we also had stream based and continuation/callback based I/O, the latter being basically what JavaScript does.
- lmm 5y ago> No, this is just not true, are we using the same JavaScript? JavaScript's functions change only based on modified application state, not on any other side effect. If you read some file (or remote URL) multiple times, you may get different data each time. Haskell makes "functions" with this property clearly distinct from regular functions. Most languages, including JavaScript, don't. That's what matters, not whether I/O is synchronous or not. > Sure, in the current Haskell that's true. In previous iterations of Haskell this wasn't always the case though That may or may not be technically true but it's not really informative or relevant - Haskell has had monadic I/O for over 20 years and the overwhelming majority of Haskell users have never used any other kind.
- tinco 5y ago> If you read some file (or remote URL) multiple times, you may get different data each time. True, but just like in Haskell that data is not returned by the function, JavaScript functions are pure for I/O.
- tome 5y agoWhat do you mean "the function"? One can certainly write functions in JavaScript that return the result of an HTTP request, and that result can change each time the function is run. In Haskell you can't do that.
- tinco 5y agoYou can't do that in idiomatic JavaScript, at least I've never done such a thing in the past 15 years. Maybe you could share an example to show me?
- tome 5y agoSure, synchronous XHTMLHttpRequest.send() is an example https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ... Certainly it's not idiomatic but that's not lmm's point. The point is that it's possible. In Haskell it's not possible.
- tinco 5y agoSure it's possible, you can use unsafePerformIO just fine in Haskell. It's idiomatic to not use it, just like it's idiomatic to not use synchronous I/O in JavaScript. Imo it's also not really interesting to talk about non idiomatic use of a language but I guess we disagree there.
- tome 5y agoIt seems to me that there is a qualitative difference between having synchronous HTTP requests in the JavaScript standard library and having access to System.IO.Unsafe.unsafePerformIO in Haskell. Still, I take your point that in theory JavaScript could remove all synchronous I/O side effecting functions and replace them with continuation-based ones. Anyway, we've wandered pretty far off the main thread, which wasn't mine to begin with, so I'll let lmm take up the discussion again if he wants.
- 5y ago