6 ms·

In my own personal monad opinion, the 'strongest' idea of a monad to me is just a function or program. monad 1 | monad 2 | monad 3 It doesn't have to be compl

In my own personal monad opinion, the 'strongest' idea of a monad to me is just a function or program. monad 1 | monad 2 | monad 3 It doesn't have to be complicated.

MaxRegret 3y ago
I think the article is an attempt to make your idea more precise. What if monad 3 could use the result of monad 1, not just monad 2? Then you couldn't write that computation using your pipeline metaphor. The article is saying that by judicious use of a "strength" function, you can in fact write any monadic computation as such a pipeline (or composition of monadic functions).
- koolala 3y ago
  If my example of pipeline is a limited metaphor, couldn't it be expanded? I love this subject but it's traditionally over-complex, so I appreciate the correction and explaination. How could "strength" be applied generically to programs outside of Haskell? Could the concept of pipelines be extended? Is programming too 1 dimensional? There must be ways to do this.
  - MaxRegret 3y ago
    I think the user-friendly way to make programming less one-dimensional is what we usually do, outside of shell pipelines; give names to intermediate values: do x <- computation1 y <- computation2 x computation3 x y ...turning a one-dimensional sequence of operations into a data-flow graph represented textually. But, and perhaps this is an academic question, what if you're stuck in a context where you can only create computations by composing functions in a sequence, without giving names to intermediate results? Shell pipelines, for example, without using temporary files or other tricks. Then, using this idea of strong and weak monads, and if you were used to thinking of computations as elements of a monad type, you might realize that all you need to add is a "strength" operator, and you would regain the full expressivity of data flow graphs. This operator would take a computation and bundle it with value, producing a new computation that does the same computation, but bundles its result with the extra value you supplied. So you've given every computation a side-channel that ferries any data you like through it, unchanged. Computations further down the chain can access both values. I lack the imagination to see how this example works out in shell, because there we don't have the luxury of multiple input and output values (just single pipes of data). But it's nice to know that just the strength operation is enough to express arbitrary computation graphs, with names being given to inputs and outputs.
Sharlin 3y ago
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.

In my own personal monad opinion, the 'strongest' idea of a monad to me is just a function or program. monad 1 | monad 2 | monad 3 It doesn't have to be complicated.

MaxRegret 3y ago

I think the article is an attempt to make your idea more precise. What if monad 3 could use the result of monad 1, not just monad 2? Then you couldn't write that computation using your pipeline metaphor. The article is saying that by judicious use of a "strength" function, you can in fact write any monadic computation as such a pipeline (or composition of monadic functions).

koolala 3y ago
If my example of pipeline is a limited metaphor, couldn't it be expanded? I love this subject but it's traditionally over-complex, so I appreciate the correction and explaination. How could "strength" be applied generically to programs outside of Haskell? Could the concept of pipelines be extended? Is programming too 1 dimensional? There must be ways to do this.
- MaxRegret 3y ago
  I think the user-friendly way to make programming less one-dimensional is what we usually do, outside of shell pipelines; give names to intermediate values: do x <- computation1 y <- computation2 x computation3 x y ...turning a one-dimensional sequence of operations into a data-flow graph represented textually. But, and perhaps this is an academic question, what if you're stuck in a context where you can only create computations by composing functions in a sequence, without giving names to intermediate results? Shell pipelines, for example, without using temporary files or other tricks. Then, using this idea of strong and weak monads, and if you were used to thinking of computations as elements of a monad type, you might realize that all you need to add is a "strength" operator, and you would regain the full expressivity of data flow graphs. This operator would take a computation and bundle it with value, producing a new computation that does the same computation, but bundles its result with the extra value you supplied. So you've given every computation a side-channel that ferries any data you like through it, unchanged. Computations further down the chain can access both values. I lack the imagination to see how this example works out in shell, because there we don't have the luxury of multiple input and output values (just single pipes of data). But it's nice to know that just the strength operation is enough to express arbitrary computation graphs, with names being given to inputs and outputs.

Sharlin 3y ago

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.