3 ms·

The whole point of the article is that the right-associativity of Haskell monads makes them not simple pipelines because it allows this: a -> b -> c \

The whole point of the article is that the right-associativity of Haskell monads makes them not simple pipelines because it allows this: a -> b -> c \_______^ so c gets the results of both a and b "for free".

koolala 3y ago
So how do you generalize this idea to programs and functions? My framing is "incorrect" I think but it feels far easier to reason about. Couldn't this same idea be applied generically to all computer programs? Could its valuable situational properties ever be done in a way that is language neutral with arbitrary program monads?
- kfixjviv 3y ago
  The main reason that monads are restricted to fancy languages like Haskell is that the type system has to support their definition. There are some examples of attempted implementations the list monad in other languages on RosettaCode https://rosettacode.org/wiki/Monads/List_monad https://rosettacode.org/wiki/Monads/List_monad Caveat emptor, though. A lot of that page is erroneous. A few years ago I fixed up the definition for F#, which is perhaps the closest thing to a language for ordinary Joes in which true monadic style can be defined/achieved.
  - koolala 3y ago
    Monads are a concept in types and a specific theory but if you throw the rigid definition away can't they be done anywhere? For example, if I have three RaspberryPi's, isn't there a way I could compose them as monads? That is what I mean - it isn't a fair thing for me to say - but I feel like they would be so much more tangible if we could think about them as literal Things like this. Which is why my original example was composition of Programs instead of composition in a specific Programming Language.
    - kfixjviv 3y ago
      Each Raspberry Pi could perform a function that was notionally passed to the monadic bind operator, but really a monad is the rules under which the Raspberry Pis would be connected. From Wadler's paper "The Essence of Functional Programming": "2.1 What is a monad? For our purposes, a monad is a triple (M,unitM,bindM) consisting of a type constructor M and a pair of polymorphic functions. unitM :: a-> M a bindM :: M a-> (a-> M b)-> M b These functions must satisfy three laws, which are discussed in Section 2.10." So the monad is a functor plus a few operations and laws. It is an algebraic structure, not a type of object or function.
      - kfixjviv 3y ago
        By the way, "throwing the rigid definition away" would be completely missing the point. The rigid definition is the essence of monads.
        epgui 3y ago
        People who think they hate maths will always try to get rid of the maths and tell themselves that that makes the maths way better.
      - koolala 3y ago
        It's important to me because if the pattern was actually useful then we should be able to use it anywhere and talk about it. It seems obvious that the pipe "workflow" pattern as they call it isn't the end-all for program composition - so how can we fix and expand it? It seems fixable. Another context question: How would you define a monad in Microsoft Excel? For context, that is my favorite programming language. It seems perfectly capable at doing strong monad composition better than a Linux shell. I just want monads be real and tangible! Examples in reality instead of Math.
        kfixjviv 3y ago
        You are going to be disappointed. What on earth makes you convinced that a monad can be implemented in Excel? You don't understand what a monad is, so you can't know whether Excel is "perfectly capable" of it or not. Read a bunch of monad tutorials, learn Haskell, hey, even develop some "mathematical maturity" if you can get over your disdain for math. That is the way to make progress. It's not helpful to want monads to be tangible objects. It doesn't matter how much you want it. The world doesn't work like that.
a1369209993 3y ago
What right-associativity? The parentheses go like this: [1, 2] >>= \x -> ([x, 10*x] >>= \y -> [x*y]) There is no associativity of >>=, any more than there's associativity of + in: 12 + 34*(56 + 7*8) (Probably less, since + and * are distributive.)
- Sharlin 3y ago
  You're right, there's no right-associativity actually involved, but the article probably used the term because the code kinda looks right-associative if you squint. The point is that the rightmost >>= is evaluated first, which lets the y lambda capture x. The article put the parens like this: test3 = [1, 2] >>= (\x -> [x, 10*x] >>= \y -> [x*y]) which to a non-Haskeller like me does make it look more right-associative than it actually is – and as the article showed, you can actually make it "left-associative" in the obvious way, which would indeed compile fine and be equivalent to the "right-associative" way if the y lambda didn't refer to x. test3 = ([1, 2] >>= \x -> [x, 10*x]) >>= \y -> [x*y]
- hgsgm 3y ago
  It's practically left associative, via the fish operator notation. https://gjoncas.github.io/posts/2020-05-30-monad-associativity-law.html https://gjoncas.github.io/posts/2020-05-30-monad-associativi...

koolala 3y ago

So how do you generalize this idea to programs and functions? My framing is "incorrect" I think but it feels far easier to reason about. Couldn't this same idea be applied generically to all computer programs? Could its valuable situational properties ever be done in a way that is language neutral with arbitrary program monads?

kfixjviv 3y ago
The main reason that monads are restricted to fancy languages like Haskell is that the type system has to support their definition. There are some examples of attempted implementations the list monad in other languages on RosettaCode https://rosettacode.org/wiki/Monads/List_monad https://rosettacode.org/wiki/Monads/List_monad Caveat emptor, though. A lot of that page is erroneous. A few years ago I fixed up the definition for F#, which is perhaps the closest thing to a language for ordinary Joes in which true monadic style can be defined/achieved.
- koolala 3y ago
  Monads are a concept in types and a specific theory but if you throw the rigid definition away can't they be done anywhere? For example, if I have three RaspberryPi's, isn't there a way I could compose them as monads? That is what I mean - it isn't a fair thing for me to say - but I feel like they would be so much more tangible if we could think about them as literal Things like this. Which is why my original example was composition of Programs instead of composition in a specific Programming Language.
  - kfixjviv 3y ago
    Each Raspberry Pi could perform a function that was notionally passed to the monadic bind operator, but really a monad is the rules under which the Raspberry Pis would be connected. From Wadler's paper "The Essence of Functional Programming": "2.1 What is a monad? For our purposes, a monad is a triple (M,unitM,bindM) consisting of a type constructor M and a pair of polymorphic functions. unitM :: a-> M a bindM :: M a-> (a-> M b)-> M b These functions must satisfy three laws, which are discussed in Section 2.10." So the monad is a functor plus a few operations and laws. It is an algebraic structure, not a type of object or function.
    - kfixjviv 3y ago
      By the way, "throwing the rigid definition away" would be completely missing the point. The rigid definition is the essence of monads.
      - epgui 3y ago
        People who think they hate maths will always try to get rid of the maths and tell themselves that that makes the maths way better.
    - koolala 3y ago
      It's important to me because if the pattern was actually useful then we should be able to use it anywhere and talk about it. It seems obvious that the pipe "workflow" pattern as they call it isn't the end-all for program composition - so how can we fix and expand it? It seems fixable. Another context question: How would you define a monad in Microsoft Excel? For context, that is my favorite programming language. It seems perfectly capable at doing strong monad composition better than a Linux shell. I just want monads be real and tangible! Examples in reality instead of Math.
      - kfixjviv 3y ago
        You are going to be disappointed. What on earth makes you convinced that a monad can be implemented in Excel? You don't understand what a monad is, so you can't know whether Excel is "perfectly capable" of it or not. Read a bunch of monad tutorials, learn Haskell, hey, even develop some "mathematical maturity" if you can get over your disdain for math. That is the way to make progress. It's not helpful to want monads to be tangible objects. It doesn't matter how much you want it. The world doesn't work like that.

a1369209993 3y ago

What right-associativity? The parentheses go like this: [1, 2] >>= \x -> ([x, 10*x] >>= \y -> [x*y]) There is no associativity of >>=, any more than there's associativity of + in: 12 + 34*(56 + 7*8) (Probably less, since + and * are distributive.)

Sharlin 3y ago
You're right, there's no right-associativity actually involved, but the article probably used the term because the code kinda looks right-associative if you squint. The point is that the rightmost >>= is evaluated first, which lets the y lambda capture x. The article put the parens like this: test3 = [1, 2] >>= (\x -> [x, 10*x] >>= \y -> [x*y]) which to a non-Haskeller like me does make it look more right-associative than it actually is – and as the article showed, you can actually make it "left-associative" in the obvious way, which would indeed compile fine and be equivalent to the "right-associative" way if the y lambda didn't refer to x. test3 = ([1, 2] >>= \x -> [x, 10*x]) >>= \y -> [x*y]
hgsgm 3y ago
It's practically left associative, via the fish operator notation. https://gjoncas.github.io/posts/2020-05-30-monad-associativity-law.html https://gjoncas.github.io/posts/2020-05-30-monad-associativi...