<div class="gmail_quote">On Tue Dec 16 2014 at 5:54:22 PM Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 16/12/2014, at 9:05 pm, aman mangal <<a href="mailto:mangalaman93@gmail.com" target="_blank">mangalaman93@gmail.com</a>> wrote:<br>
> 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)?<br>
<br>
What would you use a ‘return statement’ *for*?<br>
You might as well ask why Erlang doesn’t have an ‘assigned GO TO’ statement.<br></blockquote></div><div class="gmail_quote"><div>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.<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Moreover, is there a good alternate to avoid nested case statements?<br>
<br>
Why avoid them?  Give a *real* example where nested case expressions<br>
(not “statements”, Erlang doesn’t strictly speaking *have* “statements”)<br>
are a problem.<br>
<br></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Making more functions just seems tedious.<br>
<br>
That’s not the question, surely?  The question is whether it is *more*<br>
tedious than other alternatives.  And whether it leads to *better* code.<br>
<br>
> Using catch statement seems another good alternate but my intuition is that it is not good practice, is it?<br>
<br>
‘try . . . catch’ is another ‘case’-like structure; that would be to<br>
cast out devils by means of Beelzebub.<br></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It seems to be a goood rule in all discussions like this to focus on<br>
some actual concrete cases from real code.<br>
<br>
</blockquote></div>