<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 7, 2018 at 6:28 AM Kenneth Lundin <<a href="mailto:kenneth@erlang.org">kenneth@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><h3><span>EEP-0049 Value-based Error handling mechanisms</span></h3>
<a name="m_-7754378175197588968_m_-8746844382255813045_m_7746986015464219343_The_problem_to_solve" id="gmail-m_-7754378175197588968gmail-m_-8746844382255813045gmail-m_7746986015464219343gmail-The_problem_to_solve"></a><h4><span></span><span></span></h4><ul><li> We don't like a language construct which is hard coded to support ok,<span style="font-family:monospace,monospace">{ok,Result}, {error,Reason}</span>.
</li><li> the use of underscore <span style="font-family:monospace,monospace">_ <~</span> to mean a match with <span style="font-family:monospace,monospace">ok</span> is not a hit, it will make programs harder to read
</li><li> We are against the introduction of <i>unwrapexprs</i> that cannot be used everywhere where expressions are allowed.
</li><li> The <i>unwrapexpr</i> changes the scoping rules and can not be used in nested expressions and not outside begin ... end.
</li></ul>
<p>It is perfectly possible to use throw and try catch to replace or
simplify deeply-nested case ... end expressions in the same way as
the proposed language extension does.
</p>
<a name="m_-7754378175197588968_m_-8746844382255813045_m_7746986015464219343_Example" id="gmail-m_-7754378175197588968gmail-m_-8746844382255813045gmail-m_7746986015464219343gmail-Example"></a><h5><span></span><span>...<br></span></h5>
<a name="m_-7754378175197588968_m_-8746844382255813045_m_7746986015464219343_Summary" id="gmail-m_-7754378175197588968gmail-m_-8746844382255813045gmail-m_7746986015464219343gmail-Summary"></a><h4><span></span><span>Summary </span></h4>
<ul><li>We say no to the proposed language extensions. We don't think they are general enough and we also see some problems with them.
</li><li> The same effect can be achieved safely with the current language using throw, try...catch.
</li><li> Encouraging <code>ok, {ok,Result}, {error,Reason}</code> as
results from functions can be done in other ways, for example through
library functions. These values should not be special to the <i>language</i>.
</li><li>We also want to thank the author for a very well thought through and well documented proposal which has triggered us to think about possible
solutions in this area. We really appreciate the effort.</li></ul><p>/Kenneth, Erlang/OTP Ericsson</p></div></div></div></div></blockquote><div>I'd like to come back and revisit this.</div><div><br></div><div>I won't re-expand on my disdain for try...catch based control-flow for common cases, but I was wondering what would the opinion of the OTP team be if I were to re-work the proposal towards a less <i>opinionated</i> approach to this control flow, something possibly more in line with Elixir's <span style="font-family:monospace">with</span>. <br></div><div><br></div><div>Currently the simplest way to transform this proposal is probably to allow the pattern on the left-hand-side of <~ to be any pattern, and only escape the begin...end construct as a short-circuit return:</div><div><br></div><div><font face="monospace">begin</font></div><div><font face="monospace"> {ok, X} = exp(), % hard crash if it doesn't match</font></div><div><font face="monospace"> {ok, X} <~ exp(), % if it fails, begin...end returns the value of the non-matching term</font></div><div><font face="monospace"> ...<br></font></div><div><font face="monospace">end</font><br></div><div><br></div><div>This gets rid of the <span style="font-family:monospace">_ <~ rhs()</span> magic syntax, drops prescriptiveness of <span style="font-family:monospace">ok | {ok, T} | {error, R}</span> returns, but maintains high-level control flow that doesn't risk transforming non-local returns into values (which forces rewriting unrelated code to work nicely with high-level conditional flows and clashes with value-based error handling) and establishing a sort of conditional pipeline. It does lose some of the safety mentioned in the original proposal, but we can't maintain that safety without normalizing acceptable good or error values, which the OTP team has mentioned not wanting to do at the language level.</div><div><br></div><div>Of course the logical expansion of it is going for:</div><div><br></div><div><div><font face="monospace">case <br></font></div><div><font face="monospace"> begin</font></div><div><font face="monospace"> {ok, X} = exp(), % hard crash if it doesn't match</font></div><div><font face="monospace"> {ok, Y} <~ exp(), % if it fails, begin...end returns the value of the non-matching term</font></div><div><font face="monospace"> ...<br></font></div><div><font face="monospace"> end</font></div><div><font face="monospace">of</font></div><div><font face="monospace"> {ok, Good} -> ...;</font></div><div><font face="monospace"> {error, Reason} -> ...;<br></font></div><div><font face="monospace">end<br></font></div></div><div><br></div><div>which brings in whether a proposal rework that goes for something closer to Elixir's <a href="https://www.openmymind.net/Elixirs-With-Statement/">with</a> would be interesting.</div><div><br></div><div>Let me know if there's interest and I can rework things. I keep feeling the pain of complex validation flows time and time again there, particularly whenever there is one single good path and many bad paths possible for each validation step.<br></div><div><br></div></div></div>