<div dir="ltr"><div>For Elixir, we end-up duplicating the else clause on all <- patterns. This was the implementation that performed better but it makes Dialyzer unhappy. In a nutshell, you convert each X <- Y into:</div><div><br></div><div style="margin-left:40px">case Y of</div><div style="margin-left:40px">  X -> rest_of_begin</div><div style="margin-left:40px">  ...AllClausesInCase -> ...<br></div><div style="margin-left:40px">end</div><div><br></div><div>It may be easier to implement.<br></div><div><br></div><div>We also discussed an approach where the else clauses would be moved to an anonymous function that we would call on every failed <-, to reduce the code duplication. However, that was expensive. There have been discussions about inlining anonymous function calls in the compiler, or at least removing the intermediate anonymous function "object", which may make it a better implementation.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 3:19 PM Fred Hebert <<a href="mailto:mononcqc@ferd.ca">mononcqc@ferd.ca</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>Quick update to mention I've managed to set things up in a way where only rewrites using case expressions could be used to make things work (assuming tokenizer support for the other constructs): <a href="https://gist.github.com/ferd/2f1134fd88615354fbf89c068216b259" target="_blank">https://gist.github.com/ferd/2f1134fd88615354fbf89c068216b259</a></div><div><br></div><div>I guess the question I have there is whether we feel this is acceptable, or way too risky when it comes to constructs such as parse transforms which work with the AST. It feels like this is a change that causes "minimal displacement" but ends up being a much larger burden down the road when people writing tools that work on Erlang code and abstract representations have to be aware of these translations and subtle variations in order to maintain user-intended semantics intact. Would it make sense to look at a much deeper integration introducing new forms all the way to core erlang (which could likely ignore <span style="font-family:monospace">begin ... else ... end</span> and rewrite with case expressions there)? <br></div><div><br></div><div>EEPs tend to come with a reference implementation so I'm starting to look at ways I can feasibly pull this off on my own.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 23, 2020 at 9:57 AM Fred Hebert <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</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" class="gmail_attr">On Fri, Oct 23, 2020 at 7:32 AM Björn Gustavsson <<a href="mailto:bjorn@erlang.org" target="_blank">bjorn@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">
<br>
We have handled the addition of new keywords in the past by having an<br>
option to disable them (keeping the new keywords as atoms). That we<br>
will allow the compilation of old code that uses the keyword as an<br>
atom. (We did that when we introduced try/catch.)<br></blockquote><div> </div></div><div dir="ltr">Sounds good to me. <br></div><div dir="ltr"><br></div><div>I'd be fine speccing the addition of an 'else-style' keyword for <span style="font-family:monospace">begin ... end</span>. A funny thing to consider is that if we add '<span style="font-family:monospace">else</span>', people will be really confused about why<span style="font-family:monospace"> begin ... end</span> has it but not <span style="font-family:monospace">if ... end</span>. I figure this is out of scope for this specific RFC, but worth pointing out regardless.</div><div><br></div><div>I'll try to find slack time over the next week or two to edit EEP-49, including the quoted workaround and possibly some additional research. But to do a tl:dr;, this is heading for:</div><div><ul><li><span style="font-family:monospace">begin ... end</span> with an optional <span style="font-family:monospace">begin ... else ... end</span> variant</li><li>The "unwrap expression" is replaced by a "match or return" mechanism.<br></li><li>since there is no longer any unwrapping we can switch form <span style="font-family:monospace"><~</span> to <span style="font-family:monospace"><-</span> as an operator and keep rather familiar semantics</li><li>the <span style="font-family:monospace">else</span> keyword (or anything else that takes its place) would require compiler options that specify using it as an atom to allow compilation of older modules which do not use the construct and rely on the same keyword. <br></li></ul></div><div>I'm gonna have to look into whether this can still be safely emulated with simple case expression being shifted around or if it requires fancier a lower-level rewrite. I doubt it can be that easy to do because we have to intersperse non-conditional code in there and a goto-like mechanism could make more sense (an option would also be to use a ref with a throw/catch, but I'd rather avoid the cost of generating a ref per block of conditionals). Anyway, while I look into this, that'll give time to get more potential feedback or information from the OTP team, which Kenneth has hinted at.<br></div></div>
</blockquote></div>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</blockquote></div>