[eeps] EEP XXX: Pattern-test operator

[Erik Søe Sørensen]

So - Richard, should we continue with this as a change to EEP 14 or as a
modified EEP XX?

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 "?=".)
It looks like something can be done in a way that fits well into the
existing algorithm.
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".
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.
(Looking at generated code, I notice that 'orelse' and 'andalso' in guards
gives rise (in R14B03) to some surprising - and suboptimal - code.)

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...
(Taking a step back, with "?=", 'if' could replace 'case' as the general
internal construct. That, however, would probably be too radical.)

Den 16. apr. 2012 10.49 skrev Erik Søe Sørensen <eriksoe@REDACTED>:

> "Assignment attempt operator", eh?  I think I can work with that. :-)
> 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.
>
> (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.)
>
> Den 16. apr. 2012 02.53 skrev Richard O'Keefe <ok@REDACTED>:
>
> Let's see where we can get if we
>> (1) Fix the operand order to be compatible with =
>> (2) Fix the spelling of the operator to be something
>>    that suggests matching and suggests testing (for
>>    me, with the languages I am familiar with, ~
>>    really doesn't do either)
>> (3) Spell out the semantics, specifically the escape/
>>    propagation of bindings, clearly and explicitly.
>>
>>        Pattern ?= Expression
>>
>> is a familiar operator (well, it is if you know Eiffel,
>> where it's called "assignment attempt") which addresses
>> (1) and (2).  I've spent some time on (3), thought I was
>> getting close, and realised I'd failed.  In
>>
>>        p(X) when Y ?= 10 div X orelse Y ?= oops ->
>>            q(Y).
>>
>> I definitely want Y to be visible in the body.  With
>>
>>        p(X) when Y = 10 div X ; Y = oops -> q(Y).
>>
>> the scope rules would have been very nearly automatic.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20120418/d72e261f/attachment.htm>