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 User
mkValidUser name age = do
validatedName ← validateName name
validatedAge ← validateAge age
pure $ User validatedName 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
Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.
The exception handling question mark, spelled ? and abbreviated and pronounced eh?, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t do foo()?.bar()?.baz()? in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.
and you want to construct the following using these 3 functions
fn :: Maybe String-> Maybe Int
in a Rust-type syntax, you’d call
str?.toInt()?.double()?.isValid()
in Haskell you’d have two different operators here
str >>= toInt <&> double >>= isValid
however you can define this type class
classChainable f a b fb where(?.) :: f a -> (a -> fb) -> f b
instance Functorf=> Chainable f a b b where(?.) = (<&>)
instance Monadm=> Chainable m a b(m b) where
(?.) = (>>=)
and then get roughly the same syntax as rust without introducing a new language feature
str ?. toInt ?. double ?. isValid
though this is more general than just Maybes (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do this
classChainable a b fb where
(?.) :: Maybe a -> (a -> fb) -> Maybe b
instance Chainable a b b where
(?.) = (<&>)
instance Chainable a b (Maybe b) where
(?.) = (>>=)
restricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of “you can’t easily get at the wrapped type”. To get at b instead of Maybe b you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they’re awkward in a monadic context) whereas Rust will gladly hand you that b in the middle of an expression, and doesn’t force you to name the point.
Or to give a concrete example, iffoo()? {...} is rather awkward in Haskell, you end up writing things like
foo xy= bar >>= baz x y
where
baz x yTrue= x
baz x yFalse= y
, though of course baz is completely generic and can be factored out. I think I called it “cap” in my Haskell days, for “consequent-alternative-predicate”.
Flattening Functors and Monads syntax-wise is neat but it’s not getting you all the way. But it’s the Haskell way: Instead of macros, use tons upon tons of trivial functions :)
I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of “couldn’t foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz”, and while the strings are long as hell they are much better explanations for a problem than a stack trace is.
deleted by creator
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?
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 validatedAge
for 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
Possible
type 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
Either
is a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle theLeft
/error case, if any of theEither
s end up being aLeft
value then it’ll correctly “short-circuit” and the function will evaluate to thatLeft
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
Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.
The exception handling question mark, spelled
?
and abbreviated and pronouncedeh?
, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t dofoo()?.bar()?.baz()?
in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.Note: Lemmy code blocks don’t play nice with some symbols, specifically < and & in the following code examples
This isn’t a language level issue really though, Haskell can be equally ergonomic.
The weird thing about
?.
is that it’s actually overloaded, it can mean:A?
that returnsB?
A?
that returnsB
you’d end up with
B?
in either caseSay you have these functions
toInt :: String -> Maybe Int double :: Int -> Int isValid :: Int -> Maybe Int
and you want to construct the following using these 3 functions
fn :: Maybe String -> Maybe Int
in a Rust-type syntax, you’d call
str?.toInt()?.double()?.isValid()
in Haskell you’d have two different operators here
str >>= toInt <&> double >>= isValid
however you can define this type class
class Chainable f a b fb where (?.) :: f a -> (a -> fb) -> f b instance Functor f => Chainable f a b b where (?.) = (<&>) instance Monad m => Chainable m a b (m b) where (?.) = (>>=)
and then get roughly the same syntax as rust without introducing a new language feature
str ?. toInt ?. double ?. isValid
though this is more general than just
Maybe
s (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do thisclass Chainable a b fb where (?.) :: Maybe a -> (a -> fb) -> Maybe b instance Chainable a b b where (?.) = (<&>) instance Chainable a b (Maybe b) where (?.) = (>>=)
restricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of “you can’t easily get at the wrapped type”. To get at
b
instead ofMaybe b
you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they’re awkward in a monadic context) whereas Rust will gladly hand you thatb
in the middle of an expression, and doesn’t force you to name the point.Or to give a concrete example,
if foo()? {...}
is rather awkward in Haskell, you end up writing things likefoo x y = bar >>= baz x y where baz x y True = x baz x y False = y
, though of course baz is completely generic and can be factored out. I think I called it “cap” in my Haskell days, for “consequent-alternative-predicate”.
Flattening Functors and Monads syntax-wise is neat but it’s not getting you all the way. But it’s the Haskell way: Instead of macros, use tons upon tons of trivial functions :)
You can say it’s half-arsed if you like, but it’s still vastly more convenient to write than if err != nil all over the place
Can anybody explain the rationale behind this?
Exceptions don’t exists and ask errors must be handled at every level. It’s infuriating.
I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of “couldn’t foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz”, and while the strings are long as hell they are much better explanations for a problem than a stack trace is.
Hahaha, fuck no, I’ve dealt with exception-less code enough in my life, kthxbye
I think you missed a memo. Exceptions are bad and errors as values are in… I’ll have Harold forward it to you
deleted by creator
btw lua handles error in exactly the same way