Tag Info

Hot answers tagged

32

Monads are neither good nor bad. They just are. They're tools that are used to solve problems like many other constructs of programming languages. One very important application of them is to make life easier for programmers working in a purely functional language. But they are useful in non-functional languages; it's just that that people rarely ...


23

The problem with IO a = worldState -> (a, worldState) is that if this were true then we could prove that forever (putStrLn "Hello") :: IO a and undefined :: IO a are equal. Here is the proof courtesy of dolio (2010, irc): forever m = m >> forever m = fix (\r -> m >> r) = {definition of >> for worldState -> (a, worldState)} fix ...


20

Views #1 and #2 are incorrect in general. Any data-type of kind * -> * can work as a label, monads are much more than that. (With the exception of the IO monad) computations within a monad are not impure. They simply represent computations that we perceive as having side effects, but they're pure. Both these misunderstandings come from focusing on the ...


19

Using Maybe (or its cousin Either which works basically the same way but lets you return an arbitrary value in place of Nothing) serves a slightly different purpose than exceptions. In Java terms, it's like having a checked exception rather than a runtime exception. It represents something expected which you have to deal with, rather than an error you did ...


14

Scala is also inspired by Ocaml, which uses Option. Options are an Ocaml standard type that can be either None (undefined) or Some x where x can be any value. Options are widely used in Ocaml to represent undefined values (a little like NULL in C, but in a type and memory safe way)... I think the name chosen is a matter of taste.


12

Here's a trivial answer: any change to the state monad's state is due to any actions ran in the monad. If indeed the “WorldState -> (a, WorldState)” explanation claims the same property, with WorldState being a pure value that only the IO monad changes, it's wrong. Time changes, the content of files, the state of handles, etc. can change independently of ...


8

I wrote a blog post on the topic of how to model IO as a form of asymmetric coroutine communicating with the runtime system for your language. (It is admittedly the third part of a series) http://comonad.com/reader/2011/free-monads-for-less-3/ That post covers a bit of why it is awkward to reason about the semantics of 'world-passing'.


8

An exception can carry more information about the source of a problem. OpenFile() can throw FileNotFound or NoPermission or TooManyDescriptors etc. A None does not carry this information. Exceptions can be used in contexts that lack return values (e.g. with constructors in languages that have them). An exception allows you to very easily send the ...


7

I'll bite!!! Monads by themselves aren't really a raison d'etre for Haskell (early versions of Haskell didn't even have them). Your question is a bit like saying "C++ when I look at the syntax, I get so bored. But templates are a highly advertised feature of C++ so I looked at an implementation in some other language". The evolution of a Haskell ...


7

Reading the documentation on F#'s Option type, it looks like it does behave pretty much exactly like the Maybe type in Haskell, in that it can model either 'nothing' (None in F#, Nothing in Haskell), or a value of its argument type (Some in F#, Just in Haskell). In Haskell, however, Maybe is also a monad, and the plumbing is such that it allows for ...


6

See Tackling the Awkward Squad. The big reason is RealWorld state models of the IO monad don't work well with concurrency. SPJ in this readable classic favors using an operational semantics to understand it.


5

The main complaint about RealWorld state models is that, as TacTics says, world-passing doesn't necessarily work with concurrency. But Wouter Swierstra and Thorsten Altenkirch showed how to reason about concurrency as "world-passing" effect, with a fixed-but-arbitrary sequence of interleaving threads in their paper "Beauty in the Beast: A Functional Sematics ...


5

Let’s call functions that return a monadic value “actions”. The type signature for >>= in p >>= q says that: Given a nullary action p that returns something of type a And given a unary action q that takes an a and returns something of type b You can chain them to get a nullary action that returns something of type b It is worth remembering ...


4

Kind of an old question but it's a really good one, so I'll answer. You can think of monads as blocks of code for which you have complete control over how they're executed: what each line of code should return, whether the execution should stop at any point, whether some other processing should happen between each line. I'll give some examples of things ...


4

Haskell enforces Referential Transparency: given the same parameters, every function always returns the same result, no matter how many times you call that function. That means, for example, that on Haskell (and without Monads) you can not implement a random number generator. In C++ or Java you can do that using global variables, storing the intermediate ...


4

Programmers all write programs, but the similarities end there. I think programmers differ far more than most programmers can imagine. Take any long-standing "battle", like static variable typing vs runtime-only types, scripting vs compiled, C-style vs object-oriented. You will find it impossible to rationally argue that one camp is inferior, because some of ...


4

"Maybe" is not a replacement for exceptions. Exceptions are meant to be used in exceptional cases (for instance: opening a db connection and the db server is not there although it should be). "Maybe" is for modeling a situation when you may or may not have a valid value; say you are getting a value from a dictionary for a key: it may be there or may be not - ...


4

View 1: Monad as a label "Consequently, this Int value has been marked as value that came from a process with IO therefore this value is "dirty"." "IO Int" is not in general a Int value (although it may be in some cases such as "return 3"). It is a procedure which outputs some Int value. Different executions of this "procedure" may yield different Int ...


4

To the extent that monads serve to isolate a generalized computation strategy from the specifics of its algorithm or implementation, they can be seen as a basis or theoretical foundation for AOP. I found an interesting paper called Monads as a theoretical foundation for AOP (PDF) that gives this idea a more thorough treatment.


4

Just a hint: a -> M b is more general than M a -> M b, since you can do a -> M a any time with return.


4

The place Java and C# fall down in implementing monads is if you bind a function a -> m b where a != b you can't return this - you need to construct a default b to create the m b where in Haskell Nothing is a valid m b construction as well as Left anything can supplant Right anything. You have an Either monad here which is what we OO folks prefer over ...


4

Fist I'd ask myself: Is having an invalid User a code bug or a situation that can normally occur (for example someone entering a wrong input to your application). If it's a bug, I'd try to ensure that it can never happen (like using smart constructors or creating more sophisticated types). If it's a valid scenario then some error processing during runtime ...


3

What you need is MonadPlus (see also Haskell wiki). It defines mzero :: m a which represents an unspecified error, and mplus :: m a -> m a -> m a which tries the second computation, if the first one fails. A few auxiliary functions are provided too: -- Extends `mplus` to lists of computations: msum :: MonadPlus m => [m a] -> m a -- Fails a ...


3

The term unit comes from category theory where we define a monad as two natural transformations unit : Identity ~> m and join : m x m ~> m. In case you're curious, bind f = join . fmap f. return comes from do notation where return looks appropriately algol-ish. It's actually debatable whether this was a good name since it tends to suggest that return ...


3

As Benjamin Hodgson mentioned in his comment, the term lift is usually applied to lifting non-monadic functions into the monad. As for why the function is specifically called return, that is because it is used in the do syntactic sugar, which is meant to resemble an imperative C/ALGOL style code block, which typically used the return keyword to return a ...


2

Turns out the paradigm described (badly) in the question does exist, and is known as "multi-staged programming", "staged metaprogramming", or similar words to that effect. According to this taxonomy, the question is envisaging the "static generator" (as opposed to those systems that use staging for dynamic code generation). Staged programming is distinct ...


1

So my question is, in the same way that we've come to favor composition over inheritance, does it also make sense to favor monads over inheritance? In non-OO languages, yes. In more traditional OO languages, I would say no. The issue is that most languages don't have type specialization, meaning you can't make Flier<Squirrel> and ...



Only top voted, non community-wiki answers of a minimum length are eligible