Monads and Intensionality – Lucid is not an aberration
billwadge.wordpress.com
Monads and Intensionality – Lucid is not an aberration
1–10 of 38 posts
Re: Monads and Intensionality – Lucid is not an aberration
#2It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field.
> So what is the IO monad, the most famous of them all?
IO is the State monad where the state is the entire universe.
Re: Monads and Intensionality – Lucid is not an aberration
#3This is pretty much the standard definition of monads, just everything is being talked about in terms of domains and sets rather than functions and values. Maybe that's clearer to some people; I find it less clear than talking about what a monad does pointwise.
> This is my best shot. What I don’t understand is where the side effect comes in. The other monads I’ve discussed don’t produce side effects.
This is putting the cart before the horse. The goal is to have a sensible way of modelling computations that have side effects, to be able to talk even slightly denotationally about (side-effecting) computations. An element of D* is a side-effecting computation that produces a value that's an element of D; this isn't something that comes out of the monad model but something we put into it, because the point of the exercise is to talk about side-effecting computations that produce values.
The point is that such computations are monads in a very natural way: d* is the value d (or, equivalently - in a very concrete sense in Haskell, since it's a lazy language - a computation without side effects that produces the value d), f* is composition with the pure computation f (so f* (x) has the same side effects as x: it's the computation that consists of executing x and then applying f to its result). The sum of two elements in D* x + y is executing x, then executing y, then summing their results (and thus its side effects are the side effects of x followed by the side effects of y), and the collapse from D* * to D* is that we execute a computation and then execute the resulting computation.
The advantage of this is the same as the advantage of modelling anything else as a monad: we get a formal representation of side-effecting computations that has some useful algebraic properties. The monad is a means for working with the effect we want to work with, whether that effect is partiality, nondeterminism, streaming, or general side effects. We shouldn't be surprised that side effects come out of using a monadic model of side effects, any more than we should be surprised that nondeterminism comes out of using a monadic model of nondeterminism.
Re: Monads and Intensionality – Lucid is not an aberration
#4[deleted]
Re: Monads and Intensionality – Lucid is not an aberration
#5This is pretty much the standard definition of monads, just everything is being talked about in terms of domains and sets rather than functions and values. Maybe that's clearer to some people; I find it less clear than talking about what a monad does pointwise. > This is my best shot. What I don’t understand is where the side effect comes in. The other monads I’ve discussed don’t produce side effects. This is putting…
Wouldn't infinite streams more naturally form a comonad than a monad, though? They're coinductive types.
Re: Monads and Intensionality – Lucid is not an aberration
#6This is pretty much the standard definition of monads, just everything is being talked about in terms of domains and sets rather than functions and values. Maybe that's clearer to some people; I find it less clear than talking about what a monad does pointwise. > This is my best shot. What I don’t understand is where the side effect comes in. The other monads I’ve discussed don’t produce side effects. This is putting…
Re: Monads and Intensionality – Lucid is not an aberration
#7This is pretty much the standard definition of monads, just everything is being talked about in terms of domains and sets rather than functions and values. Maybe that's clearer to some people; I find it less clear than talking about what a monad does pointwise. > This is my best shot. What I don’t understand is where the side effect comes in. The other monads I’ve discussed don’t produce side effects. This is putting…
Wouldn't infinite streams more naturally form a comonad than a monad, though? They're coinductive types.
Depends how you're using them. Apparently Lucid finds this "diagonal" approach to streams - which is not the normal way of streams in most programming languages - to be useful, in which case the monad model is a good fit.
Re: Monads and Intensionality – Lucid is not an aberration
#8This is pretty much the standard definition of monads, just everything is being talked about in terms of domains and sets rather than functions and values. Maybe that's clearer to some people; I find it less clear than talking about what a monad does pointwise. > This is my best shot. What I don’t understand is where the side effect comes in. The other monads I’ve discussed don’t produce side effects. This is putting…
https://news.ycombinator.com/formatdoc
Thanks, have added spaces after the *s.
Re: Monads and Intensionality – Lucid is not an aberration
#9It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.
> IO is the State monad where the state is the entire universe.
Maybe in the early days, but that doesn't really describe how it works these days (in particular, async exceptions). In practice it's been used as a "sin bin" type for any side effect that we don't know how to model nicely.
Re: Monads and Intensionality – Lucid is not an aberration
#10It's unfortunate that so many people in the software profession have a negative attitude towards these concepts. Despite its unfortunately alien name, monad is a great abstraction for patterns that come up often in this field. > So what is the IO monad, the most famous of them all? IO is the State monad where the state is the entire universe.
I don't have a negative attitude towards the concept of monads nor one informed by its funny name (where did you even get that notion? Programming is filled with jargon).
I do have a bit of a negative attitude towards evangelists who expect people to be impressed by ideas whose significance they routinely fail to communicate. Functional programming enthusiasts seem to really want the rest of us to care about monads but never quite get around to telling us why, and that's on them.
I get that, say, Result types and List types both can wrap objects and both compose with themselves in some nice ways when they do. And as a mathematically curious person, I think this is a fun observation. But since there is very little overlap in their practical use cases I don't understand why having a formal model for that commonality is so important.
Since you said it comes up often, do you have an example of a time where you reached a solution faster by recognizing that it should be monad-shaped?