21–30 of 55 posts
Monads are red herrings , if what you're interested in is getting started with functional programming (or even Haskell specifically). It's an unfortunate flaw in the Haskell literature that makes it seem like you have to grok monads to learn Haskell; you don't. Monads enable syntactic sugar . If you're getting started with Haskell, you'll notice that when you write code that does I/O, you use a weird imperative-looki…
result = monadicObj
.action1(arg)
.action2(arg2);
result = monadicObj
. x So here it is: monads are just objects with overloaded and extended "." operator and with special function "return" that modifies object (in accordance with object meaning) and returns it's input value unchanged. That new operator allows us to bind return results if we want so. Overloading of "." allows us to implement various interesting operations - passing state, executing optional computations, executing non-deterministic computations, probabilistic computations, etc.
You incapsulate the meaning of computation inside object, so you can pass it to some evaluator without that evaluator knowing that you pass him non-deterministic computation instead of monte-carlo monad or vice-versa.
What, no one is giving the standard answer of "a monad is a monoid in the category of endofunctors?" A category is something like a set, but combining the objects with allowed operations. (How very OOP!) The available functions are first-class citizens (called arrows). The objects are the domains and ranges of the arrows, and their internal structures are not exposed. Arrow composition is associative when it is defin…
So monads allow sequences of actual actions to be packaged together and given preconditions and then executed in a safe manner (perhaps with an eye to concurrency). You get to maintain the exquisite purity of functional programming while still writing software that, you know, gets stuff done occassionally.
If you were looking for an explanation of the mathematical concept though, sorry, ain't got a scooby.
Monads are red herrings , if what you're interested in is getting started with functional programming (or even Haskell specifically). It's an unfortunate flaw in the Haskell literature that makes it seem like you have to grok monads to learn Haskell; you don't. Monads enable syntactic sugar . If you're getting started with Haskell, you'll notice that when you write code that does I/O, you use a weird imperative-looki…
It's a design pattern for encapsulation, with similar goals to OO but different methods. Rather than telling you what a monad is, I'll just tell you the goal. OO is designed to hide the dangerous parts of the world from you. The dangerous parts of the world (or at least some dangerous parts of the world) are encapsulated inside little black boxes with well defined interaction points. If you interact only through thos…
Earlier quoted context omitted.
Yes. But, more like sandbox type.
Hmm, I see. Does it also execute code, like a sort of exception handler, or is it just for limiting/allowing access to scope?
As an example, lists are monads. The operator for doing calculations with the value in a monad is >>= (pronounced "bind"). To double every item in an array, you could do:
[1, 2, 3] >>= \n -> [n * 2]
There's clearly work going on behind the scenes to pass each value in the list to the associated function as "n", and then combine all the resulting [n * 2] lists into one big list of the same type as the original. But that's all transparent to the programmer. He only sees the interface that the monad offers.
So the code (quoting from samstoke's hello world):
main :: IO ()
main = do
putStrLn "Please enter your name"
name main :: World -> World
main world = let newWorld = putStrLn world "Please enter your name" in
let (newerWorld, name) = getLine newWorld in
let newestWorld = putStrLn newerWorld ("Hello " ++ name ++ "!") in
newestWorld
A monad lets you thread implicit state through a computation.