So - Richard, should we continue with this as a change to EEP 14 or as a modified EEP XX?<br><br>On the implementation side, I've studied the present pattern match compilation algorithm (the paper and the implementation) and am pondering how best to include guards in the decision tree construction. (Handling certain parts of guards there would be a nice improvement in general, besides preparing the algorithm for handling of "?=".)<br>
It looks like something can be done in a way that fits well into the existing algorithm.<br>I'm thinking that recognizing and handling guard-top-level occurences of "=:=", "== <non-numeric constant>" and is_type() would be sufficient. (And possibly "<known-to-be-int> == <known-to-be-int>", as in "tuple_size(A) == tuple_size(B)".) Don't know about "not".<br>
Handling 'orelse' might be tricky, though; the current approach for ';' appears to be to simply duplicate the clause and let a downstream optimizer recognize the duplication, so I suppose that will work for 'orelse' as well.<br>
(Looking at generated code, I notice that 'orelse' and 'andalso' in guards gives rise (in R14B03)  to some surprising - and suboptimal - code.)<br><br>Decision tree construction is done when translating Core Erlang into Kernel Erlang; I think having "?=" in Core Erlang is the simplest approach.  I don't know which other tools would have to be adapted to such an extension of Core Erlang; but I don't see how guard->body bindings can be introduced to Erlang in an efficient manner without guard->body bindings being introduced to Core Erlang...<br>
(Taking a step back, with "?=", 'if' could replace 'case' as the general internal construct. That, however, would probably be too radical.)<br><br><div class="gmail_quote">Den 16. apr. 2012 10.49 skrev Erik Søe Sørensen <span dir="ltr"><<a href="mailto:eriksoe@gmail.com">eriksoe@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">"Assignment attempt operator", eh?  I think I can work with that. :-)<br>We might then be back to having to nudge Core Erlang, or find ways to express the bindings neatly in that representation, but that's not necessarily bad.<br>

<br>(I was somewhat disappointed to find that at present, guards aren't included in the decision tree calculation; i had hoped that the pattern/guard separation wasn't so wide in that part of the compiler.)<br><br>

Den 16. apr. 2012 02.53 skrev Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span>:<div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Let's see where we can get if we<br>
(1) Fix the operand order to be compatible with =<br>
(2) Fix the spelling of the operator to be something<br>
    that suggests matching and suggests testing (for<br>
    me, with the languages I am familiar with, ~<br>
    really doesn't do either)<br>
(3) Spell out the semantics, specifically the escape/<br>
    propagation of bindings, clearly and explicitly.<br>
<br>
        Pattern ?= Expression<br>
<br>
is a familiar operator (well, it is if you know Eiffel,<br>
where it's called "assignment attempt") which addresses<br>
(1) and (2).  I've spent some time on (3), thought I was<br>
getting close, and realised I'd failed.  In<br>
<br>
        p(X) when Y ?= 10 div X orelse Y ?= oops -><br>
            q(Y).<br>
<br>
I definitely want Y to be visible in the body.  With<br>
<br>
        p(X) when Y = 10 div X ; Y = oops -> q(Y).<br>
<br>
the scope rules would have been very nearly automatic.<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>