Having a Result[T, Err] monad that could represent either the data from a successful operation or an error. This can be generalised to the Either[A, B] monad too.
So in an above example if the result of foo() is Error, the result of the statement is Error and the rest of the program is not evaluated. Otherwise, if the result of foo() is Ok {Value = 3}, you pass 3 to the rest of the program and you get a final result Ok {Value = 4}.
So the whole idea is that you hide the if Error part by redefining how the statements are interpreted.
“Some generic class” with specific methods and laws, Monads are an algebraic structure and you want those laws included same as if you enable some type to use + you want to have a 0 somewhere and x + 0==x to hold. Like "foo" + "" == "foo" in the case of strings, just as an example.
In Rust, Result and Option actually are monads. Let’s take Option as example:
Why those laws? Because following them avoids surprises like x + 0 /=x.
Rust’s type system isn’t powerful enough to have a Monad trait (lack of HKTs) hence why you can’t write code that works with any type that implements that kind of interface. Result names >>=and_then, just like Option does so the code reads the same but you’ll have to choose between Option or Result in the type signature, the code can’t be properly generic over it.
Its how rust does error handling for example, you have to test a return value for “something or nothing” but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.
Here’s an example (first in Haskell then in Go), lets say you have some types/functions:
type Possible a = Either String a
data User = User { name :: String, age :: Int }
validateName :: String -> Possible String
validateAge :: Int -> Possible Int
then you can make
mkValidUser :: String -> Int -> Possible UsermkValidUser name age = do
validatedName ← validateName name
validatedAge ← validateAge age
pure $ UservalidatedName validatedAge
for some reason <- in lemmy shows up as <- inside code blocks, so I used the left arrow unicode in the above instead
in Go you’d have these
(no Possible type alias, Go can’t do generic type aliases yet, there’s an open issue for it)
In the Haskell, the fact that Either is a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle the Left/error case, if any of the Eithers end up being a Left value then it’ll correctly “short-circuit” and the function will evaluate to that Left value.
Without using the fact that it’s a functor/monad (e.g you have no access to fmap/>>=/do syntax), you’d end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each Left case now):
mkValidUser :: String -> Int -> Possible User
mkValidUser name age =
case (validatedName name, validateAge age) of
(Left nameErr, _) => Left nameErr
(_, Left ageErr) => Left ageErr
(Right validatedName, Right validatedAge) =>
Right $ User validatedName validatedAge
People are scared of monads and think this is better.
My brain is too smooth to imagine a solution to this using monads. Mind sharing what you got with the class?
Having a
Result[T, Err]monad that could represent either the data from a successful operation or an error. This can be generalised to theEither[A, B]monad too.Wait, that’s all monads are? some generic class
?
Nope. Monads enable you to redefine how statements work.
Let’s say you have a program and use an Error[T] data type which can either be Ok {Value: T} or Error:
var a = new Ok {Value = 1}; var b = foo(); return new Ok {Value = (a + b)};Each statement has the following form:
var a = expr; restYou first evaluate the “expr” part and bind/store the result in variable a, and evaluate the “rest” of the program.
You could represent the same thing using an anonymous function you evaluate right away:
(a => rest)(expr);In a normal statement you just pass the result of “expr” to the function directly. The monad allows you to redefine that part.
You instead write:
bind((a => rest), expr);Here “bind” redefines how the result of expr is passed to the anonymous function.
If you implement bind as:
B bind(Func[A, B] f, A result_expr) { return f(result_expr); }Then you get normal statements.
If you implement bind as:
Error[B] bind(Func[A, Error[B]] f, Error[A] result_expr) { switch (result_expr) { case Ok { Value: var a}: return f(a); case Error: return Error; } }You get statements with error handling.
So in an above example if the result of foo() is Error, the result of the statement is Error and the rest of the program is not evaluated. Otherwise, if the result of foo() is Ok {Value = 3}, you pass 3 to the rest of the program and you get a final result Ok {Value = 4}.
So the whole idea is that you hide the if Error part by redefining how the statements are interpreted.
“Some generic class” with specific methods and laws, Monads are an algebraic structure and you want those laws included same as if you enable some type to use
+you want to have a0somewhere andx + 0 == xto hold. Like"foo" + "" == "foo"in the case of strings, just as an example.In Rust,
ResultandOptionactually are monads. Let’s takeOptionas example:pure xisSome(x)a >>= bisa.and_then(b)Then we have:
Some(x).and_then(f)≡f(x)x.and_then(Some)≡xm.and_then(g).and_then(h)≡m.and_then(|x| g(x).and_then(h))Why those laws? Because following them avoids surprises like
x + 0 /= x.Rust’s type system isn’t powerful enough to have a Monad trait (lack of HKTs) hence why you can’t write code that works with any type that implements that kind of interface.
Resultnames>>=and_then, just likeOptiondoes so the code reads the same but you’ll have to choose betweenOptionorResultin the type signature, the code can’t be properly generic over it.This is the best explanation I’ve ever seen of monads: https://www.adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
For some reason, you’ll find a lot of really bad explanations of monads, like “programmable semi-colons”. Ignore those, and check out the link.
Someone else and not an expert. But Maybe types are implemented with Monads, Maybe is a common monad.
Its how rust does error handling for example, you have to test a return value for “something or nothing” but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.
Here’s an example (first in Haskell then in Go), lets say you have some types/functions:
then you can make
mkValidUser :: String -> Int -> Possible User mkValidUser name age = do validatedName ← validateName name validatedAge ← validateAge age pure $ User validatedName validatedAgefor some reason <- in lemmy shows up as
<-inside code blocks, so I used the left arrow unicode in the above insteadin Go you’d have these
Possibletype alias, Go can’t do generic type aliases yet, there’s an open issue for it)and with them you’d make:
func mkValidUser(name string, age int) (*User, error) { validatedName, err = validateName(name) if err != nil { return nil, err } validatedAge, err = validateAge(age) if err != nil { return nil, err } return User(Name: validatedName, Age: validatedAge), nil }In the Haskell, the fact that
Eitheris a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle theLeft/error case, if any of theEithers end up being aLeftvalue then it’ll correctly “short-circuit” and the function will evaluate to thatLeftvalue.Without using the fact that it’s a functor/monad (e.g you have no access to fmap/>>=/do syntax), you’d end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each
Leftcase now):mkValidUser :: String -> Int -> Possible User mkValidUser name age = case (validatedName name, validateAge age) of (Left nameErr, _) => Left nameErr (_, Left ageErr) => Left ageErr (Right validatedName, Right validatedAge) => Right $ User validatedName validatedAge