7 ms·

I assume that definition is motivated by the Haskell IO monad, but it's unfortunately inaccurate. Haskell IO is provided by the language core, but that's not wh

I assume that definition is motivated by the Haskell IO monad, but it's unfortunately inaccurate. Haskell IO is provided by the language core, but that's not what makes it a monad - in older versions of Haskell IO was not monadic, but the language still provided IO operations. Monad is just an interface that the IO type supports, which allows you to structure your code in a particular way (an imperative-looking sequence of instructions and assignments) that people find more intuitive and convenient. You can still use IO without using the monadic interface (e.g. it's also a Functor). Conversely, most other Haskell monads are implemented in pure Haskell and are fairly easy to reimplement yourself. The State monad in the standard library is pure Haskell code.

Mithaldu 13y ago
How does a complete Haskell program using non-monadic IO look like? As for "most other Haskell monads", from what i can tell they're just wrappers around the core monads with additional functionality tacked on and i consider it lazy to also call them monads instead of wrappers.
- dllthomas 13y ago
  Most monads for which you can implement a monad transformer are implemented by wrapping the monad transformer around Identity, but that's simply because you would otherwise be implementing basically the same thing twice. My impression has been that they were originally implemented directly and only transformer-ified later. Certainly, there is no reason that couldn't have been done. Identity doesn't involve any particular voodoo: newtype Identity a = Identity { runIdentity :: a } instance Monad Identity where return a = Identity a m >>= k = k (runIdentity m) Haskell originally didn't include monadic IO - it was introduced in version 1.3, IIRC. IO looked like lazy streams of events, but it was pretty messy and pretty possible to deadlock, from what I hear. Writing modern Haskell, doing IO without any use of the IO type isn't possible, but you can - in principle - avoid ever using the fact that it's a monad by simply calling unsafePerformIO immediately on any IO action. Good luck actually ordering your IO operations, though.
- danidiaz 13y ago
  Not really, they are independent of IO (you may be thinking of monad transformers, which are ways to extend an existing monad.) For example, this is the entire definition of the Maybe monad: data Maybe a = Nothing | Just a deriving (Eq, Ord) instance Functor Maybe where fmap _ Nothing = Nothing fmap f (Just a) = Just (f a) instance Monad Maybe where (Just x) >>= k = k x Nothing >>= _ = Nothing (Just _) >> k = k Nothing >> _ = Nothing return = Just fail _ = Nothing It's just a way to propagate failure when sequencing computations. (That's why the "Nothings" are always followed with more "Nothings" in the definition.) This SO question describes Haskell's pre-monadic IO: http://stackoverflow.com/questions/17002119/haskell-pre-monadic-i-o http://stackoverflow.com/questions/17002119/haskell-pre-mona...
  - dllthomas 13y ago
    A lot of monads in the mtl (State, Writer, Reader, &c) are implemented by applying their transformer to Identity. Your point stands, as that's not the only way to implement them, isn't the way many other monads are implemented, and Identity itself is implemented just in Haskell code, but it's a possible source of some of the confusion.
  - Mithaldu 13y ago
    I'm beginning to see how my definition is wrong. Right now it seems to me like the simple definition of a Monad is: It's a prettied-up workaround. A bit i think i need to clarify: In my opinion most monad explanations fall entirely flat because they explain WHAT a monad does, but NEVER explain WHY they were created in the first place; making the whole exercise somewhat akin to mathematics teaching in us-american schools. With what all the responses pointed out it seems like monads get created when a pain point of a language is so often, and so consistently worked around in the same fashion; that someone decided to make an implementation of the workaround that looks like basic syntax; regardless of whether the implementation happens in core or in the language itself. Thus for example Moose, a library that bolts object orientation syntax onto Perl, would probably also be a monad. Am i still off-track?

Mithaldu 13y ago

How does a complete Haskell program using non-monadic IO look like? As for "most other Haskell monads", from what i can tell they're just wrappers around the core monads with additional functionality tacked on and i consider it lazy to also call them monads instead of wrappers.

dllthomas 13y ago
Most monads for which you can implement a monad transformer are implemented by wrapping the monad transformer around Identity, but that's simply because you would otherwise be implementing basically the same thing twice. My impression has been that they were originally implemented directly and only transformer-ified later. Certainly, there is no reason that couldn't have been done. Identity doesn't involve any particular voodoo: newtype Identity a = Identity { runIdentity :: a } instance Monad Identity where return a = Identity a m >>= k = k (runIdentity m) Haskell originally didn't include monadic IO - it was introduced in version 1.3, IIRC. IO looked like lazy streams of events, but it was pretty messy and pretty possible to deadlock, from what I hear. Writing modern Haskell, doing IO without any use of the IO type isn't possible, but you can - in principle - avoid ever using the fact that it's a monad by simply calling unsafePerformIO immediately on any IO action. Good luck actually ordering your IO operations, though.
danidiaz 13y ago
Not really, they are independent of IO (you may be thinking of monad transformers, which are ways to extend an existing monad.) For example, this is the entire definition of the Maybe monad: data Maybe a = Nothing | Just a deriving (Eq, Ord) instance Functor Maybe where fmap _ Nothing = Nothing fmap f (Just a) = Just (f a) instance Monad Maybe where (Just x) >>= k = k x Nothing >>= _ = Nothing (Just _) >> k = k Nothing >> _ = Nothing return = Just fail _ = Nothing It's just a way to propagate failure when sequencing computations. (That's why the "Nothings" are always followed with more "Nothings" in the definition.) This SO question describes Haskell's pre-monadic IO: http://stackoverflow.com/questions/17002119/haskell-pre-monadic-i-o http://stackoverflow.com/questions/17002119/haskell-pre-mona...
- dllthomas 13y ago
  A lot of monads in the mtl (State, Writer, Reader, &c) are implemented by applying their transformer to Identity. Your point stands, as that's not the only way to implement them, isn't the way many other monads are implemented, and Identity itself is implemented just in Haskell code, but it's a possible source of some of the confusion.
- Mithaldu 13y ago
  I'm beginning to see how my definition is wrong. Right now it seems to me like the simple definition of a Monad is: It's a prettied-up workaround. A bit i think i need to clarify: In my opinion most monad explanations fall entirely flat because they explain WHAT a monad does, but NEVER explain WHY they were created in the first place; making the whole exercise somewhat akin to mathematics teaching in us-american schools. With what all the responses pointed out it seems like monads get created when a pain point of a language is so often, and so consistently worked around in the same fashion; that someone decided to make an implementation of the workaround that looks like basic syntax; regardless of whether the implementation happens in core or in the language itself. Thus for example Moose, a library that bolts object orientation syntax onto Perl, would probably also be a monad. Am i still off-track?