<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>100% +1 +1 +1</p>
<p>--</p>
<p>Bryan<br>
</p>
<div class="moz-cite-prefix">On 10/13/20 8:42 AM, Fred Hebert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFA3VZLpVoQDWiExQ=ZKELwidr5_DwEkxw-QRudfjpA-zuP+-g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><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"
moz-do-not-send="true">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"
moz-do-not-send="true"></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"
moz-do-not-send="true"></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"
moz-do-not-send="true"></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/"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
eeps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:eeps@erlang.org">eeps@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/eeps">http://erlang.org/mailman/listinfo/eeps</a>
</pre>
</blockquote>
</body>
</html>