<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 11:58 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=""><br></span>
call it what you like.<br>
it is not cryptic, because it has clarity.<br>
and it ADDRESSES THE PROBLEM, not dancing around.<br>
<br></blockquote><div> </div><div>It provides non-linear flow to a greater extent than the current proposal, and requires adding more syntax than the current proposal (both to create a label, and to match on it later on). The problem here, as defined in EEP-49, is using value-based error handling. There is little that dances more around that than "using exceptions instead of values to do value-based error handling".<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
The problems with this form also include:<br>
<br></span>
* you have to decide what happens if you specify a label that has no<span class=""><br>
match in the catch section?<br>
</span></blockquote>
<br>
what happens to any value that is not caught?<br></blockquote><div><br></div><div>It keeps going as a non-caught exception. However here you are specifically specifying a label for which there is no match.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but it seems better to limit the labels scope to the single try,<br>
and strip the labels from the return value of the try.<br></blockquote><div><br></div><div>But you can't do that if you don't capture the exception, unless you implicitly capture and re-raise all exceptions that had a label, or unless you change how exceptions work in the language. This is a much, much bigger change than what is being proposed in EEP-49.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* you have to decide what happens if you specify a pattern that eats<span class=""><br>
up multiple labels in the catch section. Is this acceptable or it<br>
breaks the spirit of the feature?<br>
</span></blockquote>
<br>
why not?<br></blockquote><div><br></div><div>in an EEP, you have to be able to explain why it makes sense, and why it doesn't make sense. You could say it makes sense because that's how other patterns work, for example. But if you simply say "why not?", then that's not a very strong rationale, is it?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* can you guard on labels?<br>
</blockquote>
<br>
what?<br></blockquote><div><br></div><div>Try ... catch expressions are allowed to guard on patterns. For example:</div><div><br></div><div><span style="font-family:monospace,monospace">try</span></div><div><span style="font-family:monospace,monospace"> Exp</span></div><div><span style="font-family:monospace,monospace">catch</span></div><div><span style="font-family:monospace,monospace"> error:{badmatch, X}:Stacktrace when X > 5 -> ...</span></div><div><span style="font-family:monospace,monospace">end</span></div><div><br></div><div>Can guards be applied to labels, or can they not? For example, you can currently pattern match on the exception class, the exception value, but not the stacktrace itself. It is not obvious that you want or do not want guards to apply to labels.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* can labels be dynamically generated or are they compile-time constructs?<br>
</blockquote>
<br>
can try expressions be generated?<br></blockquote><div><br></div><div>They can't without an evaluator, but you can generate values on which you match:</div><div><br></div><div>
<div><span style="font-family:monospace,monospace">X = f()<br></span></div><div><span style="font-family:monospace,monospace">try</span></div><div><span style="font-family:monospace,monospace"> Exp</span></div><div><span style="font-family:monospace,monospace">catch</span></div><div><span style="font-family:monospace,monospace"> error:{badmatch, X}:Stacktrace -> ...</span></div><div><span style="font-family:monospace,monospace">end</span></div><div><br></div>
will only match the badmatch exception if the value that failed was the same as what f() returned. The exception class can also be made dynamic. Should a label be made dynamic or purely static?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* the current syntax clashes with catching the result of throw({a,<span class=""><br>
ErrorCode, ReturnValue}), which means the syntax is too ambiguous to<br>
serve its actual purpose without breaking backwards compatibility<br>
</span></blockquote>
<br>
the syntax is being DISCUSSED it is NOT CURRENT.<br></blockquote><div><br></div><div>Fine: <i>The syntax you proposed and is being DISCUSSED clashes with catching the result of throw({a,<span class="gmail-"></span><span class="gmail-"> ErrorCode, ReturnValue}), which means the syntax is too ambiguous to</span></i><span class="gmail-"><i> serve its actual purpose without breaking backwards compatibility</i><br>
</span>
<br></div></div></div><div class="gmail_extra">So please, do some more work on your counter-proposal, since right now you're essentially throwing the current EEP-49 proposal out wholesale in favor of a fully different approach for which you have seemingly done little to no research, and goes completely against the objectives of having <i>value-based error handling</i>. You're free to disagree with EEP-49 and say you hate it, but I do not owe you a debate or a rubber-ducking session on how you should flesh out your counter-proposal. I'd rather use my limited time to improve the current one (biggest problem being <span style="font-family:monospace,monospace">_ <~ Exp</span> being the only way to match <span style="font-family:monospace,monospace">ok</span>, but there appears to be no great way around that outside of explicit patterns which also have problems), rather than figuring out how to make yours work when you haven't made that effort yourself.<br></div></div>