A Gentle Introduction to Monad Transformers – or, Values as Exceptions
github.com
github.com
What did we get just by doing this? Let's see:
λ> :type EitherIO
EitherIO :: IO (Either e a) -> EitherIO e a
λ> :type runEitherIO
runEitherIO :: EitherIO e a -> IO (Either e a)
So already we have a way to go between our own type and the combination we used previously! That's gotta be useful somehow.OK, looks like a pair of parentheses moved. I have seriously no idea why that is interesting or useful. Conceptually what's going on is probably not complicated, but that syntax makes it inscrutable to me. (I could be wrong and the problem could be at a deeper level of understanding.)
This is useful because we can do easy error handling in the EitherIO monad but we can't run it. We can run the IO monad but handling errors in it sucks ass.
So we handle errors in EitherIO, and make it runnable (ie. convert to the IO monad) by calling runEitherIO.
It's like calling a function that takes a pair when some other API gives you a two element list. The same kind of data, just munging the shape so things work. In pseudocode:
// EitherIO and runEitherIO in this analogy.
fun toList((a, b)) -> [a, b]
fun toPair([a, b]) -> (a, b)
// Gotta convert to a "runnable" pair before calling the function.
var latLngList = [blah, blah]
var resultPair = api1ThatRequiresPair(toPair(latLngList))
// Convert representations to do operations with a different API.
api2ThatRequiresList(toList(resultPair)) data EitherIO e a = EitherIO {
runEitherIO :: IO (Either e a)
}
But, for the sake of clarity, it can be written as data EitherIO e a = MakeEitherIO {
runEitherIO :: IO (Either e a)
}
The author pointed out two functions that this EitherIO declaration gave us. One is a constructor, MakeEitherIO, with type IO (Either e a) -> EitherIO e a
In other words, MakeEitherIO takes a value of type IO (Either e a) and returns a value of type EitherIO e a (you could think of this as "wrapping" the original IO value).The second function, runEitherIO, is an accessor function for EitherIO's named record field "runEitherIO". It has type
EitherIO e a -> IO (Either e a)
That is, runEitherIO takes a value of type EitherIO and returns the internal value of type IO (Either e a) (you could think of this as "unwrapping" the IO value).I hope that helps!
"->" is pronounced to. "::" is pronounced "is a".
EitherIO is a function from "IO (Either e a) -> EitherIO e a".
runEitherIO is a function from "EitherIO e a -> IO (Either e a).
In any function that allows using the IO monad (your main function for example) you'll you'll have:
result <- runEitherIO SomeEitherIOVariable
Result's type is "result :: Either e a". Now you just have a normal Either to deal with.
public static EitherIO<e, a> method(IO<EitherIO<e,a>> arg)
--> public static IO<Either<e,a>> method(EitherIO<e, a> arg)0: http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf
http://okmij.org/ftp/Haskell/extensible/index.html
I also know of:
http://jozefg.bitbucket.org/posts/2014-07-15-reading-extensi...
However I was wondering if there was a "Gentle introduction to extensible effects".
Edit: I found this presentation: http://ro-che.info/docs/2014-06-14-extensible-effects.html#1...
http://math.andrej.com/2012/03/08/programming-with-algebraic...
Shameless plug, I gave a talk about this at the NYC "Papers We Love" meetup. Audio & slides can be found here: http://www.mixcloud.com/paperswelove/bbloom_3_17_2014_progra...
They suffer from performance problems though as Roman discovered at ZuriHac this year: http://ro-che.info/articles/2014-06-14-extensible-effects-fa...
In the mean time , mtl is almost extensible effects and is very fast.
either :: (LoginError -> Text) -> (Text -> Text) -> (Either LoginError Text -> Text)
But shouldn't it be either :: (LoginError -> Text) -> (Text -> Text) -> (Either LoginError Text) -> TextGentle, gentle. I didn't get it at all.
[1]The Try type represents a computation that may either result in an exception, or return a successfully computed value. http://www.scala-lang.org/files/archive/nightly/docs/library/index.html#scala.util.Try
[2]http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-DualityAlso there are non-transformer ways to handle errors in Haskell, see: http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-ha...
But that doesn't mean they are as useful in every language. So other languages don't NEED tutorials on monads as much as Haskell does. This isn't because those other languages are worse (less "principled" or "explicit") than Haskell. It's because they aren't structured to make it important to have tutorials on monads. Instead you worry about whatever the specific issues are for those other languages.
If you aren't quite comfortable enough with monads to follow the first link, I found this implementing monads in python tutorial[1] to be a huge help.
For those that want to play with Monads in Python, check out PyMonad[2].
0: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
1: http://www.valuedlessons.com/2008/01/monads-in-python-with-n...
EDIT: you don't strictly need something like monad transformers, though. In general, monads are just another type class. A special one since IO is implemented with them, but other than that, they are not essential.
The fact that everybody tries to import monadic values into their languages is evidence that they would indeed be useful; the fact that such libraries are always useless in practice and incapable of even transliterating the Haskell, and often fail to even implement the full feature set of monadic values in Haskell even if you're willing to type reams of code, is why you don't use them in other languages.
You don't ignore monads in non-Haskell languages because the other languages are too powerful to need them, hurr hurr Haskell is teh weaks... you ignore monads in other languages because those languages are too weak to usefully implement them. If they could, you'd see them, and I am very, very confident over the next 10 years you're going to see more and more languages coming out that really have and really use monadic values, because they will be strong enough to do so, and once you have that, the value proposition is just too good to ignore. They are too darned useful to ignore.
Could you give a bit more detail here? From where I sit, I certainly don't see people trying to import monadic values into the languages I use, and I don't see much evidence that they'd be useful. (I've been trying to get my mind around monads and when and how to use them, and one of the problems I have in learning them is that, as far as I can tell, they don't look like the solution to any problem I've ever actually had.)
And getting to write large amounts of my system inside monads (because of lots of mutable state)... that doesn't look like a solution to me. It looks more like a problem.
Are there high-level abstractions that would simplify my view of this? Probably. Would getting those abstractions to behave as needed on the low level be a net win, or a net loss? My money is on the "net loss" side.
See: http://dl.acm.org/citation.cfm?id=359579
Also, you might be interested in this: https://hackage.haskell.org/package/atom
If you care at all about security, then formal verification afforded by FP techniques should also interest you.
""" Atom
Atom is a Haskell DSL for designing hard real-time embedded software. At Eaton, we use it for automotive control systems. Based on guarded atomic actions, and similar to software transactional memory, Atom enables highly concurrent programming without the need for mutex locking. In addition, Atom performs compile-time task scheduling and generates code with deterministic execution time and constant memory use, simplifying the process of timing verification and memory consumption in hard realtime applications. Without mutex locking and run-time task scheduling, Atom can eliminate the need and overhead of RTOSs for many embedded applications. """
By importing them, I mean by writing articles like this, which invariably produces code with such an overhead to use it that nobody ever would.
They don't appear to solve any problems partially because you're already "in" a monad; program execution flow is already a monadic value itself. They partially don't appear to solve any problems because you can't really "think" in them, because, as I mentioned, most languages are simply too weak to make them convenient enough to use. And they partially don't appear to solve any problem because the samples used by all the "tutorials" are all pretty trivial; it's sort of like dismissing Object Orientation because obviously it's only useful for modeling relationships between shapes, animals, and cars or something, since that's all anybody ever talks about.
It's all in C#.
1: Hey Underscore, You're Doing it Wrong!
(Rambda looks neat, thanks for the link.)
I don't see the point you are trying to make here.
No, of course not. Are people without feet useless?
What does it mean to say that Java does not have feet?
It means that it lacks a capability for which it also lacks a need (shoes). This capability is that of expressing purity via the type system. Monads - and by extension, monad transformers - are a tool designed to assist the expression of imperative algorithms in a pure context.
The reason I phrase it this way is because people often make the mistake of assuming Haskell is lacking expressive power due to its purity. This is untrue. Haskell is perfectly capable of expressing messy, mutable, imperative algorithms just like any other language. Other languages, on the other hand, struggle to express many of the pure algorithms and data structures used in Haskell; they simply lack the ability to enforce purity within the language and are thus reduced to purity by convention.
You won't understand the fuss about keyless entry if your car doesn't have locks.
In particular, are you really trying to write Haskell code in Java/Python, or are you writing Java/Python code and still wish you had monads?
If I have to use a monad for each operation, that feels like the same order of magnitude of effort as checking for null after each operation. If it's just one monad, then it feels like the monad saves work.
For that matter, the monad may still save work, because I only have to think about how I handle Nothing in one place, at the end of the series of calls. Whereas with null, I have to think about how to handle it after each call that can return null.
foo >>= bar >>= baz
This will automatically return Nothing if any of the contained functions do. This does require all of the function to have the type (a -> Maybe b), indicating that they take a value and can return either another value, or Nothing. If you have a function with type (a -> b), indicating that it is guarenteed to return something, you can wrap it like so: foo >>= return . bar >>= baz
A complete usage might look like: f x = fromMaybe defualtValue $ Just x >>= foo >>= bar >>= bazSpend some time learning the basic Haskell syntax (it's really not that hard) and you'll be able to get to the "meat" of such articles much, much faster than if the article were written in any other language.