[erlang-questions] Why doesn't Erlang has return statement?

[aman mangal]

On Tue Dec 16 2014 at 5:54:22 PM Richard A. O'Keefe <ok@REDACTED>
wrote:

>
> On 16/12/2014, at 9:05 pm, aman mangal <mangalaman93@REDACTED> wrote:
> > I have seen similar questions before on the forum but I could never
> understand the reason behind it. Is it due to theoretical reasons such as
> return statement makes it hard to reason about the program or practical
> reasons that it is hard to implement it (this doesn't seem right but I
> cannot think of anything else)?
>
> What would you use a ‘return statement’ *for*?
> You might as well ask why Erlang doesn’t have an ‘assigned GO TO’
> statement.
>
yes exactly but that also makes the reasoning about the program harder.
Even if we keep that aside, as from the discussions, Erlang has only
expressions, no statements as such.

>
> > Moreover, is there a good alternate to avoid nested case statements?
>
> Why avoid them?  Give a *real* example where nested case expressions
> (not “statements”, Erlang doesn’t strictly speaking *have* “statements”)
> are a problem.
>
> When I am using pattern matching, I wonder what if the function returned
something else. More specifically the return could be {ok, Result} |
{error, Reason}. This can happen in a sequence of statements and I end up
using nested case expressions or calling one functions after another to
handle both the cases separately.

> Making more functions just seems tedious.
>
> That’s not the question, surely?  The question is whether it is *more*
> tedious than other alternatives.  And whether it leads to *better* code.
>
> > Using catch statement seems another good alternate but my intuition is
> that it is not good practice, is it?
>
> ‘try . . . catch’ is another ‘case’-like structure; that would be to
> cast out devils by means of Beelzebub.
>
In this case, I could just follow all the good scenarios and handle all bad
scenarios once and for all in catch part of the expression.

>
> It seems to be a goood rule in all discussions like this to focus on
> some actual concrete cases from real code.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141217/a732810c/attachment.htm>