Technical note: even in languages where every expression has a value, it is possible to have an `if` form that doesn’t require an `else` value: just return nil. See, for example, Clojure: http://clojure.org/special_forms#if
Technical note: even in languages where every expression has a value, it is possible to have an `if` form that doesn’t require an `else` value: just return nil. See, for example, Clojure: http://clojure.org/special_forms#if
A typical example of a confusing return in haskell is this. Note that this always prints "hi".
foo bar = do
if bar > 5
then plugh
else do
xyzzy
return ()
print "hi"
Here xyzzy and plugh return different types; since the if statement needs the same type on both if branches, return has to be used to return a dummy value of the same type as plugh (here assumed to be ()). But it only returns it to the outside of the if; haskell's return does not influence control flow.You do get used to this pretty quickly, but there's also a tendency to move away from that style of haskell. I'd write the above more like this, using guards rather than the if, and using void to force both plugh and xyzzy to return the same type.
foo bar = go >> print "hi"
where
go
| bar > 5 = void plugh
| otherwise = void xyzzyReturn does influence the control flow in the sense that it signals the end of the monad - it's just that Haskell allows you to define and call a monad ('function') inline, which is not idiomatic in most procedural languages.
It's not too far removed from the following Python code:
> (lambda x: 5)(5)
Which, naturally, returns '5'. Lisp, of course, treats lambdas similarly; however, writing a series of statements in Lisp (like progn) is not considered idiomatic/'good' Lisp, whereas writing monads in Haskell is absolutely necessary.