If monads are the solution, what is the problem?

http://danghica.blogspot.com/2018/07/haskell-if-monads-are-solution-what-is.html

by theaeolist • 8 years ago

189 175 8 years ago

danghica.blogspot.com

foldr10• 8 years ago

The more I've learned about Haskell, the more I've come to realize that Haskell's approach to IO really has very little to do with Monads. Fundamentally, Haskell implementations sequence IO actions using hidden magic. (GHC uses dummy world variables.) As it happens, the operations for constructing IO actions from pure values and for sequencing IO actions form a Monad. But that's not really any more interesting than the fact that e.g. (\x -> [x]) and concatMap form a Monad.

newen• 8 years ago

Yep, you can alternatively use unique types (https://en.wikipedia.org/wiki/Uniqueness_type) to do IO while still maintaining referential transparency. Clean, Mercury, and Idris does this.

theoh3• 8 years ago

Reading this: https://wiki.haskell.org/IO_inside did not make me come to that conclusion.

The IO monad is noncommutative, and thus controls sequencing of operations, because of data dependencies, more or less hidden.

A "Haskell wizard" tried to tell me the ordering of operations was implemented through low-level magic a few weeks ago. The fact is that whatever ultimate form GHC might compile your code to, the sequencing is expressible in the semantics of Haskell code. Getting sequencing into the semantics is one of the problems which monads solve.

Tarean• 8 years ago

It's worth noting that the IO monad implementation is very much compiler magic and can't be done in library level haskell. Evaluation order without IO/ST is undefined in Haskell. This is similar to write barriers, you need a magic primop to specify external data dependencies.

Without that magic the compiler may inline everything, drop the 'uselss' state token and happily move your buffer freeing before the allocation - or drop it entirely.

Alternatively you could mark every function as noinline and end up with fantastically slow code.

millstone• 8 years ago

Data dependencies don't viably smuggle operation sequencing into Haskell. Consider e.g.:

   fma a b c = (a * b) + c

The sum depends on the product but this doesn't sequence anything: it may be compiled into a single fma machine instruction. More generally inlining, CSE, etc. can break apparent data dependencies.

It's simpler and cleaner to merely state that the Haskell runtime is written to execute IO actions in sequence.

richard_todd2• 8 years ago

I’m not sure I follow, since the implementation details of any given monad have very little to do with monads. It’s the fact that IO/Continuations/Etc can be just another monad that was interesting when it was discovered. It’s cleaner to have 1 pattern/framework for N domains than to have N for N.

foldr10• 8 years ago

since the implementation details of any given monad have very little to do with monads

Well, yes, that's the point. You don't need to understand anything about monads to understand how the implementation of >>= for IO forces the correct order of side effects.

mbid3• 8 years ago

You're describing my pet peeve with research in programming languages, or more generally use of abstractions in CS. What you're writing makes sense: Understand the structure of your problem, then think of similar problems you've seen before, finally try to abstract away details that are irrelevant for the solutions in each case. If you're lucky, all of these problems are an instance of one general one, and need to be solved only once. In your example, it's that IO and [] are both monads and thus share some structure.

What's often happening in PL theory, though, is that people start off with axioms/syntax and then mutilate the actual problem until it fits the syntax (still badly). That's how you get ridiculous stuff like "everything is an object" or "everything is a file". In PL theory, people will usually first make up some syntax/theory and then search for models. If physicists worked the same way, they'd write down random formulae and would then go out to find phenomena described by them. You'd probably read this comment on a cave wall.

JoshCole• 8 years ago

Axiomatic formulations of a problem do not have the same goals as abstractions. They can appear similar on the surface, but one has to do with the laying of a foundation and the other is about problem simplification. One is about allowing great leaps in understanding after a great deal of derivation, the other about the reduction of work via problem equivalence. Criticizing someone for using an axiomatic formulation rather than a proper abstraction in programming language theory is like criticizing an architect for using pencil in laying his foundation on paper rather the much more appropriate cement at the construction site.

You don't get everything is an X because of axiomatic formulation. You get it for the same sort of reason that instead of spending ages describing the configurations of atoms in front of you, you throw all that out and call it a screen. Is everything still atoms? Yes! But we can call it a screen and that makes things massively easier to reason about and so we do it, because we like to reason well. But there are still benefits to thinking the other way, thinking from the very foundations. They are just different benefits, which is why we choose to think of problems from more than one perspective.

fooker4• 8 years ago

If physicists worked the same way, they'd write down random formulae and would then go out to find phenomena described by them.

So, String Theory?

marcosdumay8• 8 years ago

Unsurprisingly, Physics get to decide what abstractions they use the same way developers decide what languages to create. They invent some notation, start describing everything they know on that notation, and if it's productive push it further and further until it breaks.

theaeolist3• 8 years ago

The "everything is an X" is what I call "foundationalism". It is a disease that started with Turing and Church, except that when they started it it was not a disease. But ever since people forgot that Y and "an encoding of Y as X" is not exactly the same thing. For some purposes it might be, but not for all purposes.

tel• 8 years ago

This, I feel, is the case with all monads. Even "free monads" are just an interesting name for an AST with embedded host-language functions.

Monad is interesting in retrospect. After you "get" X, Y, and Z you come to realize that they're all monads and then maybe you get some mileage out of the mental compression.

JadeNB4• 8 years ago

This is a crucial point. There’s almost never value in using any abstraction just once; the value comes when you learn to recognise it and apply previously learned lessons in new situations.

thanatos_dem2• 8 years ago

The incomprehension of the newbies is matched in intensity only by the smugness of the experts.

Oh good. A write up that’s aware of how unapproachable monads seem. Maybe this will actually be a good, plain-English breakdown.

Four paragraphs later:

Monads, as a mathematical concept, can be always used as a part of the semantic model, but whether they transpire into the type system of the object language is a matter of design choice.

Oh... well, never mind.

Analemma_• 8 years ago

"Monads are just monoids in the category of endofunctors, what's the problem?"

nicoburns• 8 years ago

Oh good. A write up that’s aware of how unapproachable nomads seem.

Normally I don't comment on typos (there are more important things in life!), but this one made me chuckle :)

thanatos_dem2• 8 years ago

Sorry, fixed. That’s what I get for using my phone to comment on technical things :)

rhencke• 8 years ago

The best practical description of monads I've heard, with apologies as I do not remember the quote's author:

What if, in C++, the semicolon was an operator you could overload?

willtim2• 8 years ago

I've heard Phil Wadler use this description. Why is it useful? To implement Async/Await as a library instead of a language change. Mainstream languages like C# are looking more and more like a collection of DSLs and less like a general purpose language (!).

edflsafoiewq5• 8 years ago

In C++ the semicolon separates statements. The appropriate correspondence is the comma operator, which separates values and, of course, you can overload the comma operator (much to our general chagrin) so this doesn't seem very enlightening. But this is still only discussing >>, not >>=.

FPGAhacker• 8 years ago

So I haven’t quite grasped monads or their usefulness.

Your “what-if” is completely meaningless to me, and I’m sure it’s my lack.

Could you expound upon the implications?

To me it is like saying: what if you could redefine the period at the end of a sentence....ok, but why?

Wildgoose• 8 years ago

That's how I describe monads - a programmable semicolon.

Basically {A; B} becomes semicolon(A, B).

Then you can have hidden state in the semicolon function and have complete control of how (and whether) you execute A and B, and in what order.

alipang4• 8 years ago

Here's a tutorial with a focus on more practical applications that doesn't try to go too deep into the semantics of monads, but rather tries to build intuition on a syntactic/language level - which I think is generally more helpful for beginners.

https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

willtim2• 8 years ago

Also the original paper by Phil Wadler - it is very readable: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

Jaxan• 8 years ago

Well, then you came pretty far already. This post is not a tutorial on monads. It’s really his thoughts on why he sees monads are needed in Haskell. (And not needed in, for example, ML.)

cageface• 8 years ago

Explanations of monads in the abstract always make my eyes glaze over. But if you look at a few examples of actual applications of monads I think the concept shines through clearly enough.

lmm12• 8 years ago

Monads in Haskell are used as a mechanism for scheduling evaluation, thus turning a language with a hard-to-predict evaluation strategy into a language with predictable, sequential, interactions. This makes it possible to add interactive computations such as state and input-output to the language, noting that benign (non-interactive) computations are already a part of the language, transparent to the type system.

That's a very operational/imperative perspective, and to my mind is putting the cart before the horse. To me the whole value of monads is that they let you talk about things like state and input-output in a declarative way, using plain old functions and values, rather than having to use these awkward/confusing concepts of "evaluation" and "scheduling".

alipang4• 8 years ago

There is a point to it though - continuations, for instance, have monadic structure - but at the cost of introducing a strict evaluation order. There is other work related to the linear logic that does what Monads do - provide an abstract syntax - but working better with laziness, so it's not exactly wrong to give Monads an operational perspective.

There are many perspectives one can use to understand Monads. The operational one is valid - and useful for many beginners. Of course, it's not the only way to look at them, as you point out.

a-saleh• 8 years ago

What is this linear-logic thing that does what monads do? I haven't yet grokked linear-logic (apart from the advert, that you might want to use it to reason about resource constraints), so I would like to read about this :)

lmm12• 8 years ago

The operational perspective is valid but it doesn't help to answer the question, IMO. If your answer to "what is the problem?" is "the problem is our hard-to-predict evaluation strategy", then the beginner's natural follow-up question is "why not just use a normal evaluation strategy?", and there's no good answer to that one (indeed many regard Haskell's laziness as the wrong choice; in recent times we've seen post-Haskell languages e.g. Idris moving away from it, and the best-known industrial deployment of Haskell uses a strict variant).

Meanwhile I find monads very useful in Scala, even without any laziness in sight.

edflsafoiewq5• 8 years ago

It is a completely wrong-headed perspective. Monads are just an abstraction, they do not "turn the language" into anything; code that uses monads is normal Haskell code evaluated with the same lazy strategy as all Haskell code.

Haskell also does not need monads to do IO as the author suggests. If you made monads impossible to express (as first class concepts) in Haskell, say by blasting HKTs out of the language, you would still do IO the same way, just with concrete functions instead one's parameterized over an arbitrary monad. If you made Haskell strict, you would still do IO the same way (as an unrelated note though, I believe you would need to add an unbounded looping combinator uloop : (a -> IO (a, Bool)) -> a -> IO a)

xfer5• 8 years ago

so you are telling me if getChar::Char haskell wouldn't return the same char all the time?

Or are you telling me it needs a rather elaborate type signature(World -> (Char, World)), which is entirely the point the author is making here why haskell as being a lazy language needed monads but not ML.

squiggleblaz3• 8 years ago

Yes, it doesn't at all seem right.

After I learnt Haskell, I was forever wishing the languages I work in professionally had monads. But they're all strict languages. Monads give us a nice consistent way of working with stuff inside generic wrapper types (e.g. nullable, arrays, classes and other partially applied functions, state machines, data paired with a world, partial functions converted into (more) total functions by tagging success and failed operations). My professional languages have different solutions for all of them and so it's harder to separate the rules and the mechanisms with heavy syntax

It's more that it's very convenient to think of side effecting functions operating on a world and returning a new one once you already have this powerful abstraction.

I like the fact that the type system encodes that the function has a side effect. But I don't particularly care that the language is lazy when I enjoy this benefit. They're quite independent.

platz• 8 years ago

Unfortunately, the Haskell wiki is not a great place to point beginners. The wiki's growth was rather... organic.

mattdeboard• 8 years ago

Some of the words above, especially the meandering second sentence, seem to be written to baffle rather than inform.

Ironic. The message he's referring to is the only explanation for what a monad is that has made any sense to me.

danidiaz• 8 years ago

The essence of monad is thus separation of composition timeline from the composed computation's execution timeline

I also feel that it makes sense. Haskell prefers expressions to statements. When needed, statement-like things are constructed from expressions.

solidsnack90002• 8 years ago

Monads are a way to model effects -- to mark a computation as using IO (or not), as being parallel (or not), as having exceptions (or not).

Monads in Haskell are used as a mechanism for scheduling evaluation...

This is only partially true. Any language that tries to be fully declarative -- which is to say, that tries to make all effects "part of the value" (and in consequence, part of the type) -- faces the same problems as Haskell. Idris, a strict language, uses monads to model effects.

The C language doesn't make effects part of the type signature, but C program verifiers do add effects modeling. This can be with regards to aliasing (which writes/reads could affect another pointer?), termination or timing.

It's the underlying interest in program verification that drives the use of monads in Haskell, in part because it's program verification that drives the interest in Haskell to begin with.

egillie• 8 years ago

I can’t upvote this enough. I always wish monads has been described to me this way from the get-go, it would have saved me a lot of time.

tathougies6• 8 years ago

After many years of Haskell, I was playing around in C the other day for fun. I'm writing low-level network code, and my code looks like this.

int err = socket(...) if ( err < 0 ) { do_something; }

err = listen(...) if ( err < 0 ) { do_something; }

Haskell's bind operator >>= makes abstracting this really simple. I wish I had it in C.

vikiomega9• 8 years ago

:D I think go did a good job of internalizing this

xamuel2• 8 years ago

Could you elaborate? As a C guy, I'm interested what you think would be simpler than that simple code you posted. Structurally, what you just posted (minus the details about what "socket" and "listen" mean) could be understood by a child. I'm skeptical the corresponding Haskell >>= construction would be so understandable.

tathougies6• 8 years ago

In Haskell, the 'if (err) { ... }' parts could be factored out into a new bind operator for a new monad stack. Then, you don't have to write these checks every single time. The do notation is automatically converted into the corresponding monadic code, and the algebraic monad laws guarantee that the meaning of the code is preserved.

For example, for the `if (err) {...}` cases, this is just the `ExceptT` monad transformer.

With regard to understandability, using error throwing code in Haskell is really easy. Implementing it is slightly more difficult, but so is implementing a C compiler. I mean, we shouldn't judge the utility of a thing based on whether the implementation of the thing could be understood by a child. By that measure, children would be incapable of using facebook, because they could not build it.

lmm12• 8 years ago

Children aren't born knowing C, and people who learn functional first don't tend to find it any harder. (If anything it's easier, since the meaning of "=" in Haskell is much closer to its usual meaning than the meaning in C).

dustingetz2• 8 years ago

C error checks are easy but not simple, you need enormous amounts of QA for every single change to know if you got it right (and then you still dont know)

CodexArcanum2• 8 years ago

I hate to be "that guy" but take a look at Rust if you haven't. It's pretty close to C but incorporates a lot of functional-style type magic. Your particular example is very explicitly supported by the `Result` type (which is an error-specific version of Haskell's `Either` type). It also has some syntax sugar and macro usage to make working with error types pretty simple.

tathougies6• 8 years ago

Rust is great, but not appropriate for my C use case. I did consider it, and would use it for other systems level stuff. This particular project is very close to the metal, and I want to use C and assembler. But yeah, if it was any more complicated, I would use rust. Rust is pretty great.

tikhonj3• 8 years ago

This is a somewhat misleading way to think about Haskell and monads—it puts the cart in front of the horse and obscures both how Haskell deals with effects and how monads are more general and useful than just IO. This blog post ends up mystifying more rather than demystifying.

Then again, this shouldn't be a surprise from an article that describes the Haskell ideas as "the Haskell monadic dogma"! You wouldn't expect a particularly charitable or educational account to start like that.

A much better way to think about it is to think about IO without considering monads at all. One of Haskell's core characteristics is that it explicitly separates code with side effects from code without side effects using the IO type. This is a powerful design in and of itself—it's a tool for helping programmers manage effects and not a hack around laziness.

Personally, more tools to manage effects is exactly what I want. After all, even in languages, code I write is carefully organized to separate most side-effects (API calls, database accesses... etc) from the domain logic, but this happens solely through convention and code organization. Having tools in the language to express the same separation is powerful.

Note how I never needed to talk about monads here—IO is the important concept. With this in mind the real question is not "why does Haskell need monads?" but "why are monads a useful abstraction?". This gets a bit long for an HN comment, but I wrote a blog post with my thoughts a few years back. It started like this:

I believe the notion that Haskell uses “monads” to enforce purity is rather misleading. It has certainly caused quite a bit of confusion! It’s very much like saying we use “rings to do arithmetic”. We don’t! We use numbers, which just happen to form a ring with arithmetic operations. The important idea is the number, not the ring. You can—and most people do—do arithmetic without understanding or even knowing about rings. Moreover, plenty of rings don’t have anything to do with arithmetic.
Similarly, in Haskell, we use types to deal with effects. In particular, we use IO and State and ST, all of which happen to form monads. But it is still better to say we use “the IO type” to do IO or that we use State for state than to say we use “monads” to do IO or state.

You can read the rest here: http://jelv.is/blog/Haskell-Monads-and-Purity/

This is by no means a definitive discussion of monads or anything like that; it's just a perspective I found useful for understand what Haskell gets by having a monad abstraction and why it's interesting.

agentultra4• 8 years ago

If you're looking to understand what Monads are or why they're interesting this isn't the place to figure that out.

Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` (there's talk about requiring another method, `join` but I digress). The data structure is the "context" and the interface is how you compose values from other Monads together using functions. If you can prove your implementation of the interface methods follow certain rules then you have a Monad.

Why is this pattern/abstraction/interface useful in Haskell?

I think there are several reasons. The article touches one of the most talked about: sequencing. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body.

(How it all ties together is straight-forward but requires a certain pedagogy and exposition to follow that I won't get into.)

This is, consequently, what makes Haskell the best imperative language in the world. Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones.

fooker4• 8 years ago

Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones.

These bigger, more useful programs you can write with Haskell are pretty much unreadable though. There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.

jaggederest2• 8 years ago

I wrote a fairly reasonable toy raytracer in it and I found it very readable.

The hard part was that the type system doesn't help you get your algorithms to spit out the correct answer, only the correct kind of answer. After a while I find that errors of that sort dominate the kind of things the type system helps with.

And I'm sure there are type-system-ways-to-solve-that-problem but they're nonobvious and would probably render the rest of the program more confusing. Certainly adding in error handling and state did, compared to working strictly in the IO monad.

marcosdumay8• 8 years ago

While programming, I end up reading the source of most badly documented packages on Hackage that have some interface that looks like what I'm doing. Nearly all that mostly low quality (correlates pretty well with lack of documentation) code is perfectly legible (although some have other problems).

I have never seen any language get near Haskell on the legibility of random code on the internet.

thinkpad20• 8 years ago

These bigger, more useful programs you can write with Haskell are pretty much unreadable though.

This seems somewhat baseless. Unreadable according to whom? There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). It’s the nature of software in any language to become difficult to manage as the code base becomes large; I don’t think Haskell is an exceptional offender in this category.

There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.

There certainly are reasons for that, but not the ones you laid out.

Koshkin• 8 years ago

pretty much unreadable

The last readable programming language was Algol 60.

stcredzero4• 8 years ago

Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind`

So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" Gilad Bracha covered this in a talk once.

Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body.

So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."

bitwize• 8 years ago

Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"

It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off.

The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.

jerf2• 8 years ago

'So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"'

"Monad" seems to be just beyond the complexity event horizon where it is difficult for people to get a really clean idea of what it is, so instead we've got dozens of ideas of what they are floating around, probably a good two-thirds of them with fundamental errors in them, which then contributes to the general haze surrounding the ideas.

I've got a mostly-written blog post on deck with the tentative title "Functors and Monads For People Who Have Read Too Many Tutorials", for which around 80% of it isn't explaining what they are, but systematically walking through all the errors I've seen (some of which are in the type notation for Haskell itself; the "[a]" abbreviation for what should be "[] a", if not "List a", alone has done untold damage to comprehension) before finally getting down to what the things are.

(Functor in particular is so trivial it's hard to believe it's that trivial when you finally really get it. Monad legitimately has a bit of a twist in it, and some of the specific uses of that interface take that twist and hammer it home to produce some very funky code, so the fact that it's a bit foggy isn't that big a surprise. The fog that functor has picked up by association with monad is much, much larger than the concept itself, though.)

"So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time."

It turns out no, that's just one use of them. A very big one, a very natural one, and the one that drove their prominence in the current debate... but it's not actually what the interface is "about" per se. For a good counterexample, consider the parsing monad implementations that "declaratively" [1] create a parser. It's not really about declaring execution sequences.

(There's also a non-trivial amount of confusion that arises from the fact that monad and laziness have a lot of interaction. The monad interface in a strict language would be used differently than it can be in Haskell.)

marcosdumay8• 8 years ago

A monad is a standard interface for the Interpreter pattern.

That's why you would want it. That's what you gain from them. It is a very easy standard to implement if your interpreter is simple, it can be composed into more complex interpreters, and languages that support it come with many basic implementations that you can use to construct something more complex.

The mathematicians are saying basically the same thing, but from another point of view (monoid on the category of endofunctors means computations, with an environment, that you can join one after the other) that focus much more on standards than on usability, and much more on formality than on how to make large structures out of it, so the names are different.

the_af2• 8 years ago

"Gilad Bracha covered this in a talk once."

Note that Bracha, knowledgeable as he is in his areas of interest, is painfully dismissive of things he does not understand. I watched that talk where he mentions monads (as well as non-optional static type systems, another subject he dislikes), and he comes across as ignorant and dismissive. I wouldn't use his opinions on these subjects as evidence of anything.

pwm2• 8 years ago

Realising that a monad is just a lax functor from a terminal bicategory also helps.

lmm12• 8 years ago

So it's a wrapper that implements a particular interface?

There's no wrapper, and "interface" is misleading since it suggests something that lets you invoke methods on instances whereas actually one of the core monad functions (pure aka point aka return) is something you call with a value that currently has no connection to the monad.

Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"

The categorical thing is just a joke. It's hard to talk about monads in general because they're very generic, and unfortunately IO is one of the most "monadey" of them all: it's a monad and essentially nothing else. The best way to learn to work with IO is probably to learn to work with other monads first - option or either or writer or state, things that have a canonical presentation in terms of normal functions and values. Unfortunately, even though I/O is a tiny fraction of real-world business programming (when was the last time you actually used "getChar" at your day job?), it's where people tend to start programming.

So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."

You've got it backwards. It's a way of expressing operations that lets you reason as if you were calling imperative procedures most of the time, but they are and will always remain be pure functions in a guaranteed sense that you can fall back on. There is nothing "mostly" about it and this is really important, it's what makes functional programming so useful.

machiavelli1024• 8 years ago

So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time.

No. Monad is just a “design pattern”. It’s nice that this design pattern happens to be useful to force sequential evaluation, but it’s just one of the many things that fits the monad abstraction.

didibus• 8 years ago

So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout...

Its because its actually a mathematical concept. And that's the mathematical definition.

So Haskell decided to use the same name. Now some people feel, should I explain the math concept, or its concrete representation in Haskell.

Also, its a bit more involved as an interface. In that its not enough to implement the common methods for the interface. You also have to prove that your implementation for each exhibit certain properties, specifically there needs to be an identity value which act as a neutral element, and they must be associative.

Those laws are where things get more mathematical. Because its rare in comp-sci to talk about laws and properties of functions.

foldr10• 8 years ago

Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body.

No! Monads don't guarantee sequencing. Some particular monad instances do (e.g. IO). But there's nothing inherently sequential about monads. See e.g. point 10 of the following:

https://wiki.haskell.org/What_a_Monad_is_not

agentultra4• 8 years ago

I knew I was going to get something about it wrong. Thanks for the clarification. It’s just one aspect that gets focused on because... IO and that's what the article focuses on. I got wrapped up in it too.

theaeolist3• 8 years ago

The page on "What a Monad is not" has numerous inaccuracies. I wouldn't take it too seriously.

skybrian4• 8 years ago

A side point since the author pointed to Agda as being more pure than Haskell:

In many practical situations, computations have deadlines, which may either be a timeout or the user giving up and cancelling. Languages that guarantee that functions terminate aren't as useful as you might guess, because they don't say anything about how long it will take. (It could be millions of years.)

A guarantee that a function will terminate is useful when you can avoid evaluating the function at all, while relying on a function call's existence (without compile errors) as a proof that the result exists.

It's not too often that you want to know that an answer exists without knowing the answer. This mostly comes up in mathematics when proving things.

lmm12• 8 years ago

Languages that guarantee that functions terminate aren't as useful as you might guess, because they don't say anything about how long it will take. (It could be millions of years.)

That's a theoretical problem, but is it one that comes up in practice? In my experience those languages eliminate the overwhelming majority of long-running functions, so are about as useful as you might think.

skybrian4• 8 years ago

I don't think it comes up much in practice because bugs due to non-terminating code don't actually happen much to begin with (compared to all bugs that cause hangs or timeouts), and when they do they are often found via testing. We know that a function terminates for any inputs it was tested with.

But I have little experience with these languages (I've mostly read about them) so I'd be interesting to hear about your experiences.

theaeolist3• 8 years ago

The reason for banning nonterminating functions is different, logical not computational. If you want a programming language to work as a proof checker then you want its type system to be a consistent logic, so that a program P of type A can be used as a witness that proposition A is true. Using non-terminating computation you can create such witnesses for any type, including whatever you may want to represent "False". So you have an inconsistent (useless) logic.

tufbhuf• 8 years ago

http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

emmelaich• 8 years ago

Very nice!

dustingetz2• 8 years ago

If you think Function Composition is a good thing, then it is very natural to want composition for functions of more interesting types than T→U, for example T→Promise[U] which chains intuitively but not by type.

How did I do?

jimbokun• 8 years ago

I don't know, but I think "Chain" might be a better name than "Monoid" to introduce the concept and capture the main idea.

dan-robertson2• 8 years ago

Well “Monoid” is a different sort of composible than something like like T -> Promise U.

I do agree that Monoid and Monad aren’t really great names for anyone who doesn’t come from an algebra background (ie basically anyone).

bcheung• 8 years ago

I like to think of monads as a supporting sidecar wrapper. It's almost like a plugin system; you can extend some base computation to have additional functionality for free.

This becomes really obvious how much boilerplate can be "lift"ed in something like the Flare library for PureScript (https://david-peter.de/articles/flare/).

Ex:

lift2 ( * ) (int "a" 6) (int "b" 7)

This generates 2 text fields, hooks up the change events, plumbs them into a third UI component that renders the product of the 2 fields.

Fundamentally we are just saying we want "a * b" but the monad / sidecar does all the extra work to make UI components and hook up the change events.

k__• 8 years ago

It's a way to wrap values in a mathematically defined way.

You can do it differently if you like, but you have to define the semantics yourself and find out about edge cases that math has already solved, which is the problem that is searched here, I guess...

benadamx• 8 years ago

does haskell support bofa monads?

chadcmulligan• 8 years ago

I'd say the problem with all these Monad explanations is the people reading them are in general object oriented programmers (like me) and the problem that exists in functional programming just isn't an issue in C++ / Swift etc. Its never explicitly stated because functional programmers are just so used to it, its like air.

So in a very naive way - here's the problem, When you apply a function and get a result you have no state - the function doesn't remember what happened. In object oriented programming you always have the state - its in the object, or other objects floating around, and methods can always reach out into surrounding objects to get bits of state it needs, pure functional programs can't do this - they have no state except the things that are passed as parameters. The haskellian way around this is to pass around the context of what just happened - vaguely the context is the surrounding bits of data you need to keep track of.

Monads, functors and so on are the ways that haskell keeps and manipulates the context and the value. The rules also have a very nice mathematical theory which they fit into. Most haskell intros start from maths and shoe horn the code into this - its not really necessary. This clarified it for me http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

dan-robertson2• 8 years ago

I think one thing one should ask is:

If monads are the solution to X, and we add a different solution to X to the language, then what are monads for?

Let’s say you have imperative IO. Then promises are a Monad but then you could just add language support for async and promises are not really needed as a Monad anymore.

A more functional replacement for monads could be something like algebraic effects. These could replace monads completely or they could be like multi core ocaml and only give you one shot continuations (so not allowing for list or other multi-shot monads).

In this context I like to think about the continuation Monad. In Haskell:

    newtype Cont r a = Cont { runCont :: (a -> r) -> r }

This means “some computation yielding a r which got paused part-done having just yielded an a. In some sense all monads are expressible in terms of Cont. I feel like this is largely the essence of why it is useful to have monads: they express computations which happen with some context, able to switch back and forth between things in the context and things in the normal computation. I don’t think sequencing evaluation is so important to the definition.

galaxyLogic• 8 years ago

The question monads answer is: How do I make the components of my program recombinable in ways that the result is also a monad.

Monads are like LEGOs, you can combine them in any way and what you get is something to which you can attach still more lego-pieces. It doesn't matter how exactly lego pieces are able to connect together. What matters is that you can combine any Legos together with that same mechanism and get as result something to which you can attach even more Legos. Maybe a better name for Monad would have been "Lego".

If monads are the solution, what is the problem?

Related Stories