5 ms·

> By the very nature of the monad laws, they cannot have side-effects, so they cannot be eager. I'm pretty sure monads can have side effects and be eager. It's

• SomeStupidPoint 10y ago
  IO is a monad in Haskell, right? I mean, we can talk about how it's pure in the sense that it just lifts other things in to being tied to IO programs, and it's our evaluation of them that causes mutation, but that's pedantic even to me and seems to miss the point. That sense of purity isn't what most people mean or are concerned by.
  • Guvante 10y ago
    IO a is short for roughly World -> (a, World) and is thus computationally pure. You cannot figure out what happens to the World in between but you don't need to, thus the side effects "don't exist" from a analysis standpoint. However IO follows all of the Monadic laws, I believe the comments about side effects are focusing on the side effects that show through when you try and apply the monadic laws to promises.
    • zeahfj 10y ago
      Would it be fair to say that the IO Monad get passed along implicitly with the other Monads in an eager evaluating system? Would this make it a stack? Just one that's not represented or enforced by the type system.
      • Guvante 10y ago
        I dunno, so much of the IO Monad is specific to Haskell and lazy evaluation. Generally I think of it as Haskell's quirky way of handling the real world in a pure lazy mathematical construct and not something fundamental.
    • spion 10y ago
      The "world" equivalence is not a useful way to think about it. A more useful description would be a tuple that contains two items, the first one being the description of the action to execute, and the second one being the function that will be called with the value retrieved with the action executed. So in JS notation: { action: {type: 'readFile', fileName: f}, next: content => mkPrintAction(content) }
      • wyager 10y ago
        > The "world" equivalence is not a useful way to think about it. Regardless of your opinion on the matter, that's how it's actually implemented. IO is roughly equivalent to "State RealWorld#" with some extra strictness/unboxing stuff. What you're talking about is basically the free monad over the (Request, Response -> a) functor. That would probably work, but be less performant and harder to extend. IO is nice because it's really easy to safely integrate with FFI calls. I don't think you could easily do the same with your proposal.
        • spion 10y ago
          Its just that when you mention this, the assumption is that "World" is the state of the world. Which is not true, since world is just a token to impose ordering of execution in a lazy language, but its a fake state token since its not present at run time... and that complicates the explanation further. The interpreter is simpler and easy to implement in any language too.
          • wyager 10y ago
            That's true, the compiler does optimize away the explicit dependency on the world. But it still makes sense; when you call "print", it returns a "new world" that is the state of the world after printing. You can't inspect the state of the world, so it doesn't really matter whether it's just a token or an actual description of the universe. The behavior is indistinguishable either way.
            • spion 10y ago
    • anewhnaccount 10y ago
      Honestly I've always just thought of Monads as-in Haskell as a tricky way of sequencing in the presence of lazy evaluation. Looked at this way, the "trick" is to make a data dependency between each step in the form of an argument. Since Haskell names must be bound before they're read this means we can guarantee the order in which the steps are evaluated relative to one another. Then the whole thing is wrapped up in a data structure (this latter part seems to be what people normally focus on).
    • SomeStupidPoint 10y ago
      This is a late reply, but your abstraction is leaky: World might mutate during an IO operation in a way which impacts the outcome. So the (a, World) result isnt fully deterministic from World. Even if you make each IO operation atomic, a chain of IO is still impure because the final (a, World) result depends on mutations introduced during execution. The lift to constructing an IO program from a Haskell type is pure, but the execution of that program to generate a value or effect on the system is not. So Haskell is "pure" when it comes to IO, but not in the way anyone except overly pedantic people mean the term.
      • Guvante 10y ago
        World cannot be inspected in any meaningful way in this paradigm so it is fully deterministic because the differences aren't important. > So the (a, World) result isnt fully deterministic from World. Even if you make each IO operation atomic, a chain of IO is still impure because the final (a, World) result depends on mutations introduced during execution. It is fully deterministic from World but you cannot possibly describe a World so you can't supply it nor replicate it. > So Haskell is "pure" when it comes to IO, but not in the way anyone except overly pedantic people mean the term. You can't create a World so it is pedantic in that fashion but you are able to think of the functions as pure otherwise making integration easier. A simple example is that IO happens in the correct order in Haskell because of the evaluation order not due to some external construct ensuring that lazy doesn't bite you.
        • spion 10y ago
          Which only goes to show that you can't apply real world reasoning to explain an academic concept. In this purely theoretical concept, World (which cannot be inspected) does contain the entirety of the world, including all other actions running in parallel, the current time and the state of every atom in the universe. So given the exact same state of the universe and assuming purely deterministic laws governing it (or the state of the world containing the future of the world too), yes, the action will produce the exact same output, because all other actions running in parallel or the things that will lead to the future actions are also part of that input World state. Thats my best attempt, and it still sucks! I bet someone will start wondering about the uncertainty principle there... So lets just use a free monad or thunks in a strict language function pureAction() { return function() { return impureAction(); } } function chain(pureAction, fnReturningOtherAction) { return function() { var impureResult = pureAction(); var newAction = fnReturningOtherAction(impureResult); return newAction(); } } function interpreter(mainAction) { return mainAction(); } Everything is pure, since all the functions don't do anything but return thunks for the interpreter to run. Except the interpreter which actually runs those. This isn't even a theoretical explanation - its exactly how PureScript's Eff works.
• lmm 10y ago
  The monad laws are defined in terms of equivalence of values. So if your promise is not a value then you can't even begin to talk about whether it conforms to the monad laws or not. If `Promise(someWebRequest())` starts performing the web request immediately then we can't talk about it as a value (or rather, in order to regard it as a value we have to elide some aspects of it that are actually quite crucial, such as the web request being performed).
• tpetricek 10y ago
  Perhaps you're a minority, but you're not alone - I too think that the usual narratives around monads (and many other theoretical CS concepts) are quite harmful. Do not get me wrong - they can all be useful, but not when they are conflated with many other things that some people like to have together with monads.
• spion 10y ago
  Well lets see if the first law holds. It says Promise.resolve(a).then(f) == f(a) Immediately this is not true, since `f` can throw or return a non-promise. But lets say we restrict the type of f so that it can only return promises. Once again, the statement is not correct - the executed side effect is not the same. The left side will execute with one tick delay of the microtask queue, while on the right side the side effect executes immediately. So the side effects are not equivalent. If we write `f(a); f(b);` and `Promise.resolve(a).then(f); f(b);`, in the first case the side effects will start in order; in the second case, they will start in the reverse order. If we cannot replace one side of equal sign in the law with the other and have things run exactly the same, that means equational reasoning doesnt work [1], and the law doesn't apply. In theory you could probably make monads with side-effects, but promises don't satisfy the laws. Its much easier if the monad only represents side effects but doesn't actually run them. You can think of them as redux action objects - they don't actually do anything once they are created. They only represent the side effect that will be run. For example, their internal representation could be {action: 'readFile', argument: 'path/to/file.json'}. ($) You can construct actions from other actions by chaining them with a function that will take the result from the action and produce a new action object. Those would be derived actions. You can think of them as cons cells - they have the original action, and the function that produces a new action. Example representation: {originalAction: {action: 'readFile', argument: 'path/to/file.json'}, nextActionFunction: result => printLine(result)} Finally, you pass the action to the "interpreter". The interpreter reads each action, runs the originalAction part of the cons cell, then produces a new actioin using the function in the nextActionFunction cell. It repeats that until it gets to an empty nextActionFunction cell. ($) Anoter practical representation for compile-to-js languages would be to use a thunk for the base (original) action. A thunk is a function without arguments, that when run, will produce a side-effect and return a value. The interpreter would then be simply a thunk runner. An async thunk can also be used, and thats a thunk that takes a callback that will be called with the eventual value. Still, we're only producing values without creating side effects: the laws are much easier to uphold. [1]: http://www.haskellforall.com/2013/12/equational-reasoning.html http://www.haskellforall.com/2013/12/equational-reasoning.ht...
  • zeahfj 10y ago
    How would it be less of a Monad than the IO Monad? That's the part I'm not getting. It would make sense to me if neither were considered monads.