You people live in an ivory tower.
Does understanding how a database works on a level past what most industrial programmers need to, say, leverage the value of an index make someone an ivory-tower resident? How about understanding how Paxos (ha) or Raft work? For that matter, does reading any computer science paper take me out of the realm of being a "blue-collar" programmer or does it depend on how much the paper stinks of "ivory-tower-ness?"
Have I made my point yet?
A monad is a mathematical idea. It has some learning curve, some inherent complexity that you can't magically solve.
The post you're mocking attempts to draw a helpful analogy. Maybe it helps the original author who said they couldn't find an explanation of monads that they liked. Maybe it doesn't help.
I don't see how name calling such conversation as "ivory tower" helps anyone
The stated intent of the post is "to provide an understandable notion of Monads to people who do not get them", so it seems terribly ignorant of the audience to assume that they will know Prolog, a language known for incredibly arcane syntax that has mostly been unused except for a handful of circumstances, outside of the 1980s.
The author wants to draw a parallel between Monads and Prolog's execution, however how many programmers understand Prolog? Of those programmers, how many haven't grasped monads? Even I, who has some Prolog knowledge, now has the mental and cognitive load of having to parse the Prolog that I haven't seen used properly in perhaps 6 years, on top of having to understand the analogy to monads, on top of having to understand the description of monads.
If n-gate still existed, I would pay them to review this comment chain, personally.
Not here. A monad is a programming idea. It bears some similarity to a mathematical idea, but we aren't really doing category theory here. We're doing programming.
The programming idea is simple: Anything that implements certain methods with certain semantics. That's it.
The code example basically requires no Prolog knowledge to understand. It's basically just psuedo-code.
How does that relate to “pipe operator” as in https://github.com/tc39/proposal-pipeline-operator
Are monads also linear types? I mean, if I have a monad which represents system IO state, each value of system state can only be consumed once in actual execution, I can’t split the IO state in two and print different outputs on each branch. But I can do that in a conditional expression because only one branch is ever actually realised. For IO state, data branching is only allowed when guarded by control branching.
That's a part of it, for instance see:
https://philipnilsson.github.io/Badness10k/posts/2017-05-07-...
I recently wrote a note related to this that had a useful exchange:
>> When you see a "do" block, where do you look to figure out what it's actually doing?
> If you need to know, you look at what consumes the result. If it's abstract (say it's a top level binding `... -> m a` where the m is abstract) *you don't _need_ to know "what it is actually doing" - it should be correct for any choice of* `m`.
The behavior, and the "laws" or perhaps general far-reaching properties, are the more important part of Monads I think.
> How does that relate to “pipe operator” as in https://github.com/tc39/proposal-pipeline-operator
The items in the pipeline don't have a set of laws that let you know what's going on for sure without looking at the implementation I guess.
{
X:value-that-we-care-about,
Y:something-we-only-care-about-occasionally-if-at-all
}
with error monads we don't always care if something failed (like a write) but we probably want to keep that information for later, so it just gets hidden and we can pretend we're just passing around a value (see https://fsharpforfunandprofit.com/rop/ )
I'm not particularly clear on how Haskell does the IO monad, but basically the hidden value is what lets the compiler keep track of what was done pre/post IO, allowing you to thread-the-whole-world through an IO call.
"Do" uses the same trick as that prolog example, by threading previous calculations through a function call you can force
Do
Foo1
Foo2
Foo3
( (7^7^7`mod`5`mod`2)==1, [False,True]!!(7^7^7`mod`5`mod`2) )
(True,False)
In GHC, there is a dedicated flag to spot such cases (-fwarn-type-defaults).
In general, the guarentees that the type system actually gives and also the ways to specify them appear somewhat unfinished and are also quite hard to understand, often necessitating semantic restrictions and syntactic extensions. For further examples, see for instance:
https://stackoverflow.com/questions/27019906/type-inference-...
https://stackoverflow.com/questions/14865734/referential-tra...
0. Integer is arbitrary precision while Int is bounded, machine dependent (eg. 32 or 64 bit). They are both instances of the Num type class as well as the Integral type class as we'll see later.
1. Numbers without explicit type signatures are overloaded (aka. constraint polymorphic):
λ> :t 1
1 :: Num p => p
2. As per https://www.haskell.org/onlinereport/decls.html#sect4.3.4 we have
default (Integer, Double)
3. The type of the list index operator is:
λ> :t (!!)
(!!) :: [a] -> Int -> a
Right, so in the above example if we check the type of 7^7^7`mod`5`mod`2
λ> :t 7^7^7`mod`5`mod`2
(7^7^7`mod`5`mod`2) :: Integral a => a
λ> 7^7^7`mod`5 :: Integer
3
λ> 7^7^7`mod`5 :: Int
2
default ()
λ> ( (7^7^7`mod`5`mod`2)==1, [False,True]!!fromInteger((7^7^7`mod`5`mod`2)) )
(True,True)See https://wiki.haskell.org/Polymorphism for details on parametric (ie. unconstrained) vs. ad-hoc (ie. constrained) polymorphism. In short the difference is that ad-hoc is parametric + one or more type class constraints. Eg. in:
λ> :t fmap
fmap :: Functor f => (a -> b) -> f a -> f b
Let's remove all the complexities that are introduced by the static type system for a moment, and focus on the essence. To illustrate the key point, let's use a dynamically typed logic programming language such as Prolog, where we think in terms of relations instead of functions.
Suppose we have a predicate definition of this shape:
In this case, the arguments clearly follow a pattern: They are "threaded through", starting from S0, and ending with S, in a sequence of the form S0 → S1 → S2 → ⋯ → S. This shape of argument passing is common, for example if you want to describe successive "modifications" of a data structure in the form of relations between an initial state S0 of the data, several intermediary states (S1, S2, ...), and a final state S. Or successive applications of side-effects: Think of sending packets over a network, or writing a sequence of strings to a file, where each such relation affects the state of a socket or other entity. Or when describing strings, where the string becomes successively "more known" in the form of further and further instantiation of a list of characters.You can think of monads as mechanism to make this cumbersome explicit passing of arguments implicit. For example, since the arguments that are passed around follow such a clear pattern, we could write the example above equivalently as:
and let the compiler do the necessary transformation for us. In fact, that's exactly what also happens in Prolog, using definite clause grammars (DCGs), which you can think of as a mechanism to implicitly describe such a passing of arguments, so that you do not have to write them yourself.