<div dir="ltr"><div>
Sorry for my last e-mail just going for "are you asking for GOTO". Let me dig into it on a more technical level instead. This isn't exactly a GOTO, but
rather similar to labelled breaks, which are a specialization of the jump mechanism used in a GOTO. <br></div><div><br></div><div>In any case, your suggestion isn't exactly workable with the current
syntax if only because it clashes with existing forms:</div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><span style="font-family:monospace,monospace">a: <Exp></span></div><div><br></div><div>is
essentially a new operator, ':' which binds exceptions of '<Exp>'
to the label 'a'. If you change the operator for something you dislike,
such as <~, you get:</div><div><br></div><div>
<span style="font-family:monospace,monospace">try<br>
a <~ {ok, Result} = foo()<br>
, b <~ {ok, R} = foo2()<br>
catch<br>
{a, Error_Code, Actual_Return_Value} -> ...<br>
; {b, _} -> ...<br>
end
</span><br></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Which
essentially allows the same exact syntactic form you initially disliked
(a CRYPTIC operator), just with a different choice of what the actual operator
should be. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The problems with this form also include:</div><div class="gmail_extra"><ul><li>you have to decide what happens if you specify a label that has no match in the catch section? Is it bubbled up to the next try ... catch in the stack or is it blowing up to a new exception type?<br></li><li>you have to decide what happens if you specify a pattern that eats up multiple labels in the catch section. Is this acceptable or it breaks the spirit of the feature?<br></li><li>can you guard on labels?</li><li>can labels be dynamically generated or are they compile-time constructs?</li><li>the current syntax clashes with catching the result of <span style="font-family:monospace,monospace">throw({a, ErrorCode, ReturnValue})</span>, which means the syntax is too ambiguous to serve its actual purpose without breaking backwards compatibility</li><li>the : operator is already used for fully qualified function calls, so what if you try to label a function call? You may now get <span style="font-family:monospace,monospace">label:function() </span>which is ambiguous. You may be forced to actually use an operator that isn't a colon to make your form work.<br></li></ul></div></div><div>
And even with all of that, it still does not do a very good job at value-based error handling. There are more pitfalls in this proposal than the current one, and I don't know that you can make something work well in there without introducing more syntax than the current proposal actually would.</div><div><br></div><div>I would add that while I'm fine trying to explore these patterns, I will not take the time to explore all of their nooks and crannies in full depth. This one proposal is a quick thing you've thrown my way, but it has enough pitfalls that it would take too much time to actually study it properly. It's a lot of work, and I would encourage you to possibly write your own EEP if you truly believe it should supercede EEP-49.<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 11:21 AM, <a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a> <span dir="ltr"><<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 09/11/18 17:19, Fred Hebert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
are you arguing in favor of GOTO instead of an operator?<br>
</blockquote>
<br></span>
i hope it was a temporary brownout of your mind.<div class="m_8008759970737325506HOEnZb"><div class="m_8008759970737325506h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Tue, Sep 11, 2018 at 11:09 AM, <a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a> <mailto:<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>> <<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a> <mailto:<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>>> wrote:<br>
<br>
i'm sorry to interrupt,<br>
but all you REALLY NEED is to tweak the "try..catch" a<br>
little bit,<br>
in a manner that the catch clause receives and returns<br>
more comprehensible values, the values that are clearly linked<br>
with the failed expressions and human readable.<br>
<br>
you do not need a new messy CRYPTIC operator.<br>
<br>
try<br>
{ok, Result} = foo(...)<br>
, {ok, _} = foo2(...)<br>
catch<br>
{somehow_identify_which_line<wbr>_failed,<br>
unobscured_the_rightside_value<wbr>}<br>
<br>
<br>
This here is exactly the problem -- you can't somehow identify<br>
which line failed unobscured with the right value.<br>
<br>
<br>
[irrelevant technicalities skipped]<br>
<br>
so this problem should be solved.<br>
exactly this problem.<br>
and another operator is not a solution.<br>
<br>
option 1:<br>
you introduce labels in the try's context<br>
<br>
try<br>
a: {ok, Result} = foo()<br>
, b: {ok, R} = foo2()<br>
catch<br>
{a, Error_Code, Actual_Return_Value} -> ...<br>
; {b, _} -> ...<br>
end<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 11:21 AM, <a href="mailto:e@bestmx.net">e@bestmx.net</a> <span dir="ltr"><<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/11/18 17:19, Fred Hebert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
are you arguing in favor of GOTO instead of an operator?<br>
</blockquote>
<br></span>
i hope it was a temporary brownout of your mind.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Tue, Sep 11, 2018 at 11:09 AM, <a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a> <mailto:<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>> <<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a> <mailto:<a href="mailto:e@bestmx.net" target="_blank">e@bestmx.net</a>>> wrote:<br>
<br>
i'm sorry to interrupt,<br>
but all you REALLY NEED is to tweak the "try..catch" a<br>
little bit,<br>
in a manner that the catch clause receives and returns<br>
more comprehensible values, the values that are clearly linked<br>
with the failed expressions and human readable.<br>
<br>
you do not need a new messy CRYPTIC operator.<br>
<br>
try<br>
{ok, Result} = foo(...)<br>
, {ok, _} = foo2(...)<br>
catch<br>
{somehow_identify_which_line<wbr>_failed,<br>
unobscured_the_rightside_value<wbr>}<br>
<br>
<br>
This here is exactly the problem -- you can't somehow identify<br>
which line failed unobscured with the right value.<br>
<br>
<br>
[irrelevant technicalities skipped]<br>
<br>
so this problem should be solved.<br>
exactly this problem.<br>
and another operator is not a solution.<br>
<br>
option 1:<br>
you introduce labels in the try's context<br>
<br>
try<br>
a: {ok, Result} = foo()<br>
, b: {ok, R} = foo2()<br>
catch<br>
{a, Error_Code, Actual_Return_Value} -> ...<br>
; {b, _} -> ...<br>
end<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>