<div dir="ltr"><div>Before going for a reference implementation (I'd love to get this done in time for OTP-24 but frankly I don't think I'll be solid enough to get it ready), I decided to take the time to at least update the EEP as per the comments in this thread and our latest discussions:</div><div><br></div><div><a href="https://github.com/erlang/eep/pull/18">https://github.com/erlang/eep/pull/18</a></div><div><br></div><div>This should now cover adjusted rationales, move all the older forms of the proposal to an alternative version that was dismissed, and all the examples have been rewritten to the new form to account for what was debated here.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 6, 2020 at 6:31 AM Björn Gustavsson <<a href="mailto:bjorn@erlang.org">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">On Thu, Oct 29, 2020 at 3:19 PM Fred Hebert <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>> wrote:<br>
<br>
>  Would it make sense to look at a much deeper integration introducing new forms all the way to core erlang (which could likely ignore begin ... else ... end and rewrite with case expressions there)?<br>
<br>
Yes, it would; new language features should generally introduce new<br>
forms in the Abstract format.<br>
<br>
/Björn<br>
<br>
<br>
-- <br>
Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
</blockquote></div>