a -> b -> c
\_______^
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?
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.
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.
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.
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.
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.
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)
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.
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".
Absolutely false.
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 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.
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.
[1, 2] >>= \x -> ([x, 10*x] >>= \y -> [x*y])
12 + 34*(56 + 7*8)
test3 = [1, 2] >>= (\x -> [x, 10*x] >>= \y -> [x*y])
test3 = ([1, 2] >>= \x -> [x, 10*x]) >>= \y -> [x*y]https://gjoncas.github.io/posts/2020-05-30-monad-associativi...