5 ms·

Could you explain it to me?

xupybd 4y ago
Not really. Here is one of the articles that helped me click. https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/posts/elevated-world-7.html https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/... After trying to understand it at a more fundamental level I have a suspicion that that piggy wiggies are involved.https://www.google.com/amp/s/bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/amp/ https://www.google.com/amp/s/bartoszmilewski.com/2014/10/28/...
schwurb 4y ago
I offer a simple explanation elsewhere in this thread: https://news.ycombinator.com/item?id=31652379 https://news.ycombinator.com/item?id=31652379
schwartzworld 4y ago
There's a great FP podcast, the lambdacast. They aren't making new episodes, but if you listen in order, by the time you get to the monad episode it all makes sense n
luftibus 4y ago
I recently wrote an explanation aimed at Scala developers, so if the syntax is not an obstacle this may help: https://upsolver.engineering/posts/monads-are-not-that-complicated/ https://upsolver.engineering/posts/monads-are-not-that-compl... In short: Functors (a tightly related concept) are about types that have ‘.map()’, and Monads are Functors that in addition have ‘.flatMap()’.
chombier 4y ago
A monad is for composing effectful computations. Effects are encoded using a polymorphic type with a `map` operation (called a functor), and effectful computations are functions `a -> E b` for some types `a, b` and effect `E`. A monad is exactly the plumbing you need for composing effectful computations: it turns a computation `b -> E c` into a `E b -> E c` so that you can compose `a -> E b` with `E b -> E c` to get a composed computation `a -> E c`. It does so in a way that makes effectful composition associative (i.e. the way you'd expect)
- mattnewport 4y ago
  Is Maybe/Option an effectful computation? Is List? I don't think it's really accurate to say this is what monads are "for". It's one use for monads but monads aren't "for" anything and there are monads that are not about effects.
  - chombier 4y ago
    > Is Maybe/Option an effectful computation Yes, Maybe/Options are a way of encoding partial functions/exceptions. List is a way of encoding non-determinism.
  - codebje 4y ago
    "Effect" is perhaps a broader notion than one might think: it's an effect to write to a file or mutate some variable, sure, but it's also an effect to raise an exception, goto a label, raise an exception, execute asynchronously, be one of a set of possible outcomes, and plenty of other notions. There's a name for the monad in which there is no effect: the identity monad. The heart of a monad is the bind/flatMap/and_then interface, in which the value contained in the monad is computed on to produce a new monadic value. This is where the effect occurs: something other than just running the function happens. If the bind implementation only runs the provided function then there's no effect, and it's the identity monad.
- goto11 4y ago
  Operations on a list (like map, filter) are not effectful computations. The problem with many monad explanations is they explain only particular monads. IO and State can be thought of as effectful computations, but List operations cannot. Monads are just a pattern for composing computations, it doesn't say anything about the semantics of those computations.
  - chombier 4y ago
    > but List operations cannot. They can, the effect modeled by the list monad is non-determinism.
acjohnson55 4y ago
In a typical imperative programming language, there's an "environment" that the actual lines of your program operate within. You can think of the environment as all of the sources your program can consume data from (files, databases, system clock, random number generator, keyboard, etc) and all of the sinks your program can write data into (files, databases, logs, the screen, etc). Monads are an approach to modeling the idea of running a set of statements in a particular environment, with specific input and/or output capabilities, often called "effects". In your typical programming language, you've only got one type of monad, which is the language runtime. You can do literally any type of effect at any time. That is very powerful, but it also makes programs difficult to reason about. In many typed functional programming languages, monads are used to create much more specific contexts for running sequences of computations and effects. That makes reasoning about local sections of your program way easier. One might think "why would I want to limit my power?" And the answer is you're only limiting yourself locally. It's exactly the same as how procedural programming dispensed with the all powerful GOTO, but it turned out that breaking programs into functions made them much easier to reason about. And it turns out that once you start thinking that way, you can often offload some pretty tricky logic into a well designed monad. A major caveat is that things can get pretty complex when you try to compose monads, and for me, that's where the love affair ended. There are alternative models for how to constrain effects, like algebraic effect systems, which try to be more intuitive and composable.
- goto11 4y ago
  This describes some monads but not others. IO and State can be thought of as environments supporting effects, but it doesn't really make sense to think of a List like that. The problem with many monad explanations is they only explain particular monads but then other monads become even more confusing.
  - acjohnson55 4y ago
    I've heard the List monad described as modeling nondeterminism as an effect. As you chain flatMaps, at each stage, you're consuming a discrete set of possible inputs and producing a new set of potential outputs per input. So it's a little different from thinking of your program as something that is once. Instead, you have your program being run multiple times, with the environment injecting different at each stage. I think the Future/Promise monad is similar. The environment is taking responsibility for pausing and resuming computation. But I'm curious if you have other monads in mind where the analogy fails.

Not really. Here is one of the articles that helped me click. https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/posts/elevated-world-7.html https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/... After trying to understand it at a more fundamental level I have a suspicion that that piggy wiggies are involved.https://www.google.com/amp/s/bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/amp/ https://www.google.com/amp/s/bartoszmilewski.com/2014/10/28/...

schwurb 4y ago

I offer a simple explanation elsewhere in this thread: https://news.ycombinator.com/item?id=31652379 https://news.ycombinator.com/item?id=31652379

schwartzworld 4y ago

There's a great FP podcast, the lambdacast. They aren't making new episodes, but if you listen in order, by the time you get to the monad episode it all makes sense n

luftibus 4y ago

I recently wrote an explanation aimed at Scala developers, so if the syntax is not an obstacle this may help: https://upsolver.engineering/posts/monads-are-not-that-complicated/ https://upsolver.engineering/posts/monads-are-not-that-compl... In short: Functors (a tightly related concept) are about types that have ‘.map()’, and Monads are Functors that in addition have ‘.flatMap()’.

chombier 4y ago

A monad is for composing effectful computations. Effects are encoded using a polymorphic type with a `map` operation (called a functor), and effectful computations are functions `a -> E b` for some types `a, b` and effect `E`. A monad is exactly the plumbing you need for composing effectful computations: it turns a computation `b -> E c` into a `E b -> E c` so that you can compose `a -> E b` with `E b -> E c` to get a composed computation `a -> E c`. It does so in a way that makes effectful composition associative (i.e. the way you'd expect)

mattnewport 4y ago
Is Maybe/Option an effectful computation? Is List? I don't think it's really accurate to say this is what monads are "for". It's one use for monads but monads aren't "for" anything and there are monads that are not about effects.
- chombier 4y ago
  > Is Maybe/Option an effectful computation Yes, Maybe/Options are a way of encoding partial functions/exceptions. List is a way of encoding non-determinism.
- codebje 4y ago
  "Effect" is perhaps a broader notion than one might think: it's an effect to write to a file or mutate some variable, sure, but it's also an effect to raise an exception, goto a label, raise an exception, execute asynchronously, be one of a set of possible outcomes, and plenty of other notions. There's a name for the monad in which there is no effect: the identity monad. The heart of a monad is the bind/flatMap/and_then interface, in which the value contained in the monad is computed on to produce a new monadic value. This is where the effect occurs: something other than just running the function happens. If the bind implementation only runs the provided function then there's no effect, and it's the identity monad.
goto11 4y ago
Operations on a list (like map, filter) are not effectful computations. The problem with many monad explanations is they explain only particular monads. IO and State can be thought of as effectful computations, but List operations cannot. Monads are just a pattern for composing computations, it doesn't say anything about the semantics of those computations.
- chombier 4y ago
  > but List operations cannot. They can, the effect modeled by the list monad is non-determinism.

acjohnson55 4y ago

In a typical imperative programming language, there's an "environment" that the actual lines of your program operate within. You can think of the environment as all of the sources your program can consume data from (files, databases, system clock, random number generator, keyboard, etc) and all of the sinks your program can write data into (files, databases, logs, the screen, etc). Monads are an approach to modeling the idea of running a set of statements in a particular environment, with specific input and/or output capabilities, often called "effects". In your typical programming language, you've only got one type of monad, which is the language runtime. You can do literally any type of effect at any time. That is very powerful, but it also makes programs difficult to reason about. In many typed functional programming languages, monads are used to create much more specific contexts for running sequences of computations and effects. That makes reasoning about local sections of your program way easier. One might think "why would I want to limit my power?" And the answer is you're only limiting yourself locally. It's exactly the same as how procedural programming dispensed with the all powerful GOTO, but it turned out that breaking programs into functions made them much easier to reason about. And it turns out that once you start thinking that way, you can often offload some pretty tricky logic into a well designed monad. A major caveat is that things can get pretty complex when you try to compose monads, and for me, that's where the love affair ended. There are alternative models for how to constrain effects, like algebraic effect systems, which try to be more intuitive and composable.

goto11 4y ago
This describes some monads but not others. IO and State can be thought of as environments supporting effects, but it doesn't really make sense to think of a List like that. The problem with many monad explanations is they only explain particular monads but then other monads become even more confusing.
- acjohnson55 4y ago
  I've heard the List monad described as modeling nondeterminism as an effect. As you chain flatMaps, at each stage, you're consuming a discrete set of possible inputs and producing a new set of potential outputs per input. So it's a little different from thinking of your program as something that is once. Instead, you have your program being run multiple times, with the environment injecting different at each stage. I think the Future/Promise monad is similar. The environment is taking responsibility for pausing and resuming computation. But I'm curious if you have other monads in mind where the analogy fails.