3 ms·

> But the interesting part of Haskell's I/O isn't the implementation, it's the (pure) API that it uses, and Javascript has nothing like that. No, I insist Java

• lmm 5y ago
  > There is literally no side effects except for application state mutation from the perspective of a JavaScript function (if you disregard the few deprecated synchronous API's). 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). 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. 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.
  • 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 ago
          What 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 ago
            You 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 ago
              Sure, 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.