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).

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.

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.

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".

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? Could its valuable situational properties ever be done in a way that is language neutral with arbitrary program monads?

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

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.

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.

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.

By the way, "throwing the rigid definition away" would be completely missing the point. The rigid definition is the essence of monads.

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.

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.

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.

My conviction goes like this:

1. Excel doesn't use rigid types so we can throw away all the rigid math stuff (this is where our perspectives diverge into non-sense)

2. Each Cell is a Monad

3. Each monad can be composed and reflect eachother better than any other programming language (more than Pipes like my original 1 | 2 | 3 example)

"Each cell is a monad" makes as much sense as "41 is a commutativity".

What I mean is, they can easily be used as monads - and in fact every Excel user might do so without even knowing what a monad is. Like 41 is used in commutative expressions all the time by people who don't even know what communitivity or associativity mathematically is and that is a good thing! It means its useful and intuitive!

That's why I wish we could throw out the Math, if we can't even use Monads without mathematically knowing they are Monads then no one is ever going to be using them. There must be a way that these patterns can become so intuitive, like Pipes (weak) and Excel (strong) that they speak for themselves and become tangible.

> if we can't even use Monads without mathematically knowing they are Monads then no one is ever going to be using them.

You don't need to know what a monad is to use one. Everyone who has ever written a computer program has used one. Knowing that you're using a monad, and what that means about your program structure, is the entire value proposition here - actually applying particular monad operations is utterly trivial. "Monad" belongs in the same category as "data structure", not "tree".

:)

"Everyone who has ever written a computer program has used one."

Absolutely false.

> What on earth makes you convinced that a monad can be implemented in Excel

True monads can't even be implemented in Haskell. But if we're being practical, you can totally implement monad-like things in Excel. It's almost impossible not to implement monad-like things when building anything non-trivial.

I don't think making this claim is helpful. Monads aren't found everywhere in code. Solving a problem which could be solved by monads doesn't automatically lead to code that works in a monad-like way, not in any meaningful sense.

> Monads aren't found everywhere in code.

I completely disagree... The distinction is simply that they're usually ad-hoc and not formalized, mainly because the author didn't know what they were writing and was reinventing the wheel.

> It is an algebraic structure, not a type of object or function.

Also therefore it is not that "monads can be composed with monads". Only Functions can, bhe composed. Especially functions which are the unitM() or bindM of some monad.

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.)

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]

It's practically left associative, via the fish operator notation.

https://gjoncas.github.io/posts/2020-05-30-monad-associativi...