Hacker News Reader

Comment by olavk | Hacker News Reader

Monads make a lot of sense in a pure functional language like Haskell, because it allows you to program in an imperative style when you need it, and keep the rest of the program pure and functional.

The benefit of State and IO monads is not that you can use them everywhere so you now have an imperative language. The benefit is you can explicitly delimit their use, and you still get the "easier to reason about" for the rest of the code.

For languages which already supports mutable state everywhere by default it does not make much sense to use monads for this.

View on HN

Monads are not directly related to handling side effects. Or to the famous IO that you're refeering here. What a Monad does is to force sequencing by creating a data dependency.

Speaking of IO ...

In an imperative program you get guaranteed ordering of those instructions, but that ordering is thread local, meaning that the compiler, the runtime, the kernel, the CPU are all free to reorder instructions for optimal execution and ordering between threads is forced via memory barriers, which is in fact incredibly error prone.

In an FP language such as Haskell you get the extra problem that the compiler is even more free to rewrite and execute your code in any order it sees fit due to non-strictness and to referential transparency.

What the IO monad does is to "suspend side effects" and to force ordering on evaluation. And guess what, the IO monad is useful even in your average imperative program for describing concurrent logic.

Here are the implementations I contributed to:

1. https://monix.io/docs/2x/eval/task.html (Scala)

2. https://github.com/typelevel/cats-effect (Scala)

3. https://funfix.org (JavaScript)

If you've ever worked with JS Promises, think of IO as a non-broken, pure, awesome alternative.

And this is just IO. There are other monads as well. List is a monad, Option and Either are monads ;-)

---

I recommend you let go of your misconceptions and do some learning because this is a freaking useful concept.

> I recommend you let go of your misconceptions and do some learning

Thank you for the advice! Monads seem to have some kind of smugness creation field.

I know there are other monads beside State and IO, I was specifically referencing the argument in the linked article which was about using monads for mutable state, basically turning the code into imperative style.

That wasn’t smugness. I only replied to you because those were my thoughts from 5 years ago. And I was wrong.

And yes, it’s a little troubling that such awesome concepts are not penetrating the mainstream, being so misunderstood.

I blame the available leaning resources.

It took the GC 30 years after invention to become mainstream. Functional programming, actual functional programming, apparently takes longer than that.

> That wasn’t smugness.

Maybe not. It was still condescending, though...

> What a Monad does is to force sequencing by creating a data dependency.

Does it really? Maybe this is another one of those famous misconceptions!

https://hackage.haskell.org/package/tardis-0.4.1.0/docs/Cont...

Nah, it's not really "one of those famous misconceptions".

The crucial detail is that TardisT must wrap a MonadFix, which is used for cyclical data structures. It effectively works not by making time go "backwards", but by making time loop around. It still creates a sequencing relationship.

> The crucial detail is that TardisT must wrap a MonadFix

So? The non-transformer version can still "read data before it's written". It's very hard to see any form of sequencing in that example.

> It still creates a sequencing relationship.

A sequencing relationship between what exactly?

The sequencing is described precisely in the signature of bind.

    (>>=)
        :: Monad m
        => m a         -- Left argument
        -> (a -> m b)  -- Right argument
        -> m b

You don’t need to explain an individual monad instance to notice that this signature requires “a” in order to generate “m b”.

What about the Identity monad? Does that "force sequencing"? What "sequencing relationship" does it create?

If you are convinced that the Identity monad does "force sequencing" then you are also convinced that lazy evaluation "forces sequencing" (because the Identity monad is just lazy evaluation). That would be a fairly controversion conviction. If you are not convinced that the Identity monad "forces sequencing" then can you explain in more detail the meaning of your claim "What a Monad does is to force sequencing by creating a data dependency.".

The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`.

The sequencing is very obvious from the signature of `>>=`. You don't need to know anything about any instances to see that it's there.

> The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`.

You most certainly do not! See https://news.ycombinator.com/item?id=16420742

It's in the signature. `b` has a causal dependency on `a` because `a` is on the left hand side of the arrow and `b` is on the right hand side of the arrow. That's it. Functional programming 101. There's no way around this.

The operational semantics and details of thunks are not relevant here. Tricks with `undefined` are not relevant here. This is just the meaning of the arrow type.

If that were true, why do you need a monad for sequencing? Why doesn’t function composition suffice, or something of the form a -> (a -> b) -> b?

Because the values have extra "stuff" surrounding them. That's why it's `m a` and not just `a`: the `m` holds the invisible context that enriches the `a`.

Although your example is exactly what's happening in the identity monad, because there is no extra stuff.

Monads have been called "executable semicolons", because you can define a function to be executed each time the program passes from one statement to the next.

That's not quite right.

Let's define an operator `|> = (flip $)`, which has a type signature `a -> (a -> b) -> b`, which, by your reasoning, should force sequencing too. Except it doesn't: Laziness is a bitch to work with, and `a |> f |> g` evaluates to `g(f(a))`, and g is evaluated first, which then evaluates f(a) on demand. If you consider `1 |> (+1) |> const 4`, this will evaluate to 4 without ever performing the addition.

Instead, let's compare this to the monadic equivalent. `(return 1) >>= return . (+ 1) >>= return . (const 4)`. The sequence that's being forced here isn't that (+ 1) is evaluated, it's that the `return` in `return 1` is evaluated (producing a 1) before `return . (+ 1)` is ever touched, and that _that_ return is evaluated (presumably producing an unevaluated thunk for (1 + 1)) before `return . (const 4)` is touched.

In IO world, this corresponds to guaranteeing that the IO operations happen in sequence irrespective of the order in which the pure computations they wrap are evaluated in.

> the `return` in `return 1` is evaluated (producing a 1) before `return . (+ 1)` is ever touched, and that _that_ return is evaluated (presumably producing an unevaluated thunk for (1 + 1)) before `return . (const 4)` is touched.

That's not quite right either. The former returns need never be evaluated.

    > undefined >>= (return . (const 4)) :: Identity Int
    Identity 4

Right — I should've said "that's the mechanism through which the implementation of `>>=` can force sequencing". `>>=` for Identity doesn't, most of the other common ones do, in some sense or another.

Right! `>>=` can force sequencing. It doesn't for Identity, Writer.Lazy or State.Lazy, but it can. OK, but also Arrow and Monoid can enforce a (different sort of) sequencing relationship.

Neither does monad force a sequencing relationship nor is it the only thing than can force a sequencing relationship so I can only conclude that "What a Monad does is to force sequencing by creating a data dependency" is indeed one of those misconceptions!

That's just Haskell's crazy evaluation semantics though, not something that applies to monads in general.

Indeed. But bad_user made a claim about monads in general ("What a Monad does is to force sequencing by creating a data dependency.") so all I need to do to refute it is give an example of a particular monad where the claim doesn't hold.

Monads force a denotation of sequencing. Of course you can write a language implementation where the sequencing of operation does not represent the sequencing of denotation (just as you can write a "compiler" that compiles all programs to Hello World), but, well, that's on you.

> Monads force a denotation of sequencing

Aha! Now we're on to something.

How is sequencing described in the type of join?

Tardis and the ReverseState monad are more examples of people being funny and clever by creating misleading names and mental-models instead of making libraries easy to understand.

There's no "time loop" in a cyclical data structure. There's just a data loop. Moving backward through a circular buffer, or doing arithmetic mod N, isn't "time travel"

Monads semantics are mostly what is created by bind. And bind is an operation that describes how to sequence expressions.

What you may be misunderstanding is that "sequencing expressions" does not mean "execute one expression after the other". It means, take a sequence of expressions and give it some meaning. Yes, that meaning can be "execute one after the other", or "run everything at the same time", or any other ordering. The meaning can ignore any ordering and only care about some context, or apply some order over the result in an ordered structure, or almost anything else.

I agree with your characterization, which is not at all equivalent to "What a Monad does is to force sequencing by creating a data dependency".

But TardisT is sequenced in the monadic value. It is not sequenced in its inner backwards-traveling state, but that is not part of the monadic structure.

Have you used TardisT? In order to use the backwards traveling state, you need to bind the state syntactically before you use it, just as you have to do with the forwards traveling state.

For example, a typical setup for TardisT is fixing up jump offsets for an assembler. To write this, you do something like

    assembler (Label l) = do
       fixup <- getFuture
       (curOps, offset) <- getPast
       modifyBackwards (M.insert l offset)

       let ops = curOps ++ [ Jump (M.lookup l fixup) ]
       sendFuture (ops, offset + 1)
    assembler ... = ...

Note that both the forwards and backwards traveling state needed to be bound before they were used. There is an inherent 'forwards-traveling' sequencing due to the monadic structure.

If tardist were not monadically sequenced, you ought to be able to do

    assembler (Label l) = do
       (curOps, offset) <- getPast

       let ops = curOps ++ [ Jump (M.lookup l fixup) ]
       sendFuture (ops, offset + 1)

       fixup <- getFuture
       modifyBackwards (M.insert l offset)

In this sense, the forwards traveling state is privileged (and indeed if you write anything sufficiently complicated, you'll note that you'll need to add a lot of lazy pattern matches on the backwards traveling state, but not the forwards traveling one, again indicating a notion of sequencing, despite what it may seem).

Good explanation of Tardis, but would you really describe that as "forc[ing] sequencing by creating a data dependency"?

I would get rid of the forcing part, but I think my example shows it does cause a sequential dependency ?

The separation of pure and impure code in Haskell isn't something inherent to monads but is instead a side-effect (hah) of the typing rules of the language. It's easy to see how this separation need not hold when using monads (look at any monad library in virtually any other language), but more importantly there are ways to accomplish this separation without the use of monads (an effect-tracking type system is being developed along side OCaml's algebraic effects/multicore project).

> The benefit of State and IO monads is not that you can use them everywhere so you now have an imperative language. The benefit is you can explicitly delimit their use, and you still get the "easier to reason about" for the rest of the code.

It is also important to note that apart from providing the ability to write imperative code, monads encapsulate computation. In my understanding, this is where their use shines. Getting to wrap values in such contexts in certain imperative languages could be tedious. Using a monad, one passes around the value within the context of the monad. There is a computation(aka context) that is associated with the value in the monad and that computation is performed before a value is yielded.

I agree, but Monads also simplify non-blocking concurrent programming, allowing users to think sequentially, see F# Async and Haskell IO. C# had to add Async/Await support in the compiler and I would argue it is not as pleasant as the F# version using Monads.

There are some monads (or things close to monads) that are quite common in imperative languages. Java has

  - CompletableFuture  
  - Optional  
  - Stream  
  - dependency injection can be seen as a monad

Agreed. The "islands of immutability" approach.

Monad is practically synonymous with choice. Any time you multiplex on whatever is represented by a thing to choose a different thing, you're doing a monadic operation whether you want to or not. The difference is whether or not your language has libraries for this or you have to program it yourself every time.

Conditional evaluation might be a use-case of monads, but that doesn't make them synonymous. "getLine >>= putStrLn" (read a line from stdin, write it to stdout) is a fine Haskell expression of the IO () type, but nothing in it resembles a choice. Monadic expressions can be extremely, boringly linear.

Are you sure? Of all the messages the program could have printed, of all the I/O actions imaginable, the program somehow made a choice that was not hard-coded, but based on my input! The expression multiplexes one I/O action (what to print) based on the result of another (get input from user).

That's choice!

Edit: Just realised what might be confusing. putStrLn is not an I/O action in and of itself. It's a function that multiplexes on several I/O actions based on the input value. However, crucially, that input value is pure, and thus can only be hard-coded (maybe through a bunch of indirections, but ultimatedly statically determinable.) Monadic bind is what lets us depend on another I/O result.

You're stretching. :) But even if I accept the point you're making here, that doesn't make monads synonymous with choice. Every choice is not a monad, and every monad is not a choice. This is far too reductionist. Is there no choice involved in monoids, arrows, for example? What makes monads special in this regard? And what about I/O in languages that cannot implement these concepts?

> Monad is practically synonymous with choice.

Arrows also allow you to "multiplex on whatever is represented by a thing to choose a different thing" so you'll have to be more precise!

please do not talk about Arrows publicly; it has done enough damage

Sure, so the way I understand it, a monad is a special type of arrow, so that's kille saying "You also live in France, so you'll have to be a bit more precise than Paris", no? I.e. both claims are equally true.

I think you have that the wrong way round.

I really like D's approach instead. A function declared pure can have no side effects but it can do whatever kind of mess it wants within its own code. It can have loops, assignments, reassignments, memory allocations, but it can't mutate variables outside its scope nor can it call any impure functions. I find this is a very practical compromise that lets you have the good parts of purity without ever getting the urge to write a blog post about monads.

https://dlang.org/spec/function.html#pure-functions

This is definitely cool, but monads is a more general concept. It can be used to isolate side-effects, but can also be used for many other things.

That's what Haskell calls "ST" and is far less powerful than the general notion of monads.

Haskell has the ST type for this, which is a stripped version of IO in which we can still make proper mutable inplace updates like in other languages, but there is a »runner« function called »runST«, which guarantees that the computation it contains does not leak any state to the outside – in other words, »runST <impure>« is pure from the outside. This allows embedding of mutable algorithms, e.g. inplace sorting of vectors, into pure code.

This is "const" in c++

I don't think this is the same. My C++ is getting rusty, so correct me if I'm wrong, but making a function const is mostly about making the "this" pointer const. A const function can still mutate global variables or call non-const functions, such as operator<< on cout. A pure D function can do neither of those things.

That's fair. C++ has const methods on objects, but I think nothing at global scope. But you shouldn't have global mutable state :-)

The weird thing is that you end up with something that looks like 2 different programming languages in one (talking about Haskell)

Also, Haskell's implementation of it is a bit weird an unintuitive (and the shortcuts just hide the messiness)

Given that you need state to interact with the outside world, making it more complicated in that essential area makes the learning curve harder

Do-notation does look different, but it is similar to the statement/expression distinction which is present in most imperative languages.

Does it make sense to view IO/State monads in Haskell as analogous to unsafe blocks in Rust?

I don’t think so.

- IO can be seen as a tag added to a type that brings »the outside« into scope: the console, the network, current time, the harddrive. In Rust, these are always available, regardless of the type of the expression at hand.

- IO is »viral«, in the way that things that touch IO will become IO as well; there is no way to remove IO to yield a pure value. If a function in Rust contains an unsafe block, is the whole thing unsafe? I don’t know enough Rust, but I think it’s not.

unsafe is not viral; if it was, everything would be unsafe. An unsafe block is the boundary where you tell the compiler "I've got this bit", and so it trusts you and considers it safe.

Funnily enough, “unsafe” in Haskell (e.g. unsafePerformIO) is the same way. Not viral so as to say “trust me.”

No, that does not make sense. Rust's unsafe code lets you do some things that could violate the compiler's expectations, and making sure that you're aware that you need to manually enforce those invariants. Haskell has some unsafe* functions that are exactly like that, too, such as unsafePerformIO, that are analogous. On the other hand, the IO and State monads are completely safe-to-use, using a simple abstraction to represent impurity in a pure language.

Reply on news.ycombinator.com