[eeps] EEP XXX: Pattern-test operator

[Robert Virding]

I have missed one part of the discussion here and that is about ?=:
why use ?= in a guard and not =, and what does ?= mean outside a
guard?

Couldn't we use = in a guard as well with the semantics as for other
tests: if the expression evaluates and the pattern matches then the =
"test" succeeds and the variables are bound. If the pattern does not
match then we get a failure in the guard and it behaves like it
normally does.

And what does ?= mean outside a guard? We just test the pattern to see
if it would have worked and return true/false? Just off the top of my
head.

I think if we could avoid introducing a new operator just for this
would be good.

As I said I like the idea. The main reason for not doing it was that
we never got around to it.

Robert

On 23 April 2012 14:09, Erik Søe Sørensen <eriksoe@REDACTED> wrote:
> Den 23. apr. 2012 01.21 skrev Robert Virding <rvirding@REDACTED>:
>
>> Just a few more comments. I will admit that I have fallen behind in
>> this discussion though I am definitely interested in it. So in no
>> specific order:
>>
>> - Joe is now considering his structs again and has plans of using a
>> syntax like records but without the name. For example F =
>> #{a=1,b="foo"} and perhaps F.a. This hasn't been finalised but in this
>> form it would free ~ for use. If it is a good choice I don't know yet.
>> So even if we don't get them soon we may at least get a syntax. :-)
>
>
> At present we have reached consensus on "P ?= E".  No tildes will be harmed.
>
>> - If we allowed variable binding in the guard with say Pat = Expr, how
>> far would this get us?
>
> Making variable bindings work in guards is the major part. The minor one -
> using "?=" outside of guards, either purely as testing or as left operand of
> "andalso" - has been implemented, with the exception of warnings against
> unsafe subsequent uses.
> And that minor feature is probably the largest difference between the two
> EEPs, syntax aside.
>
>> - Just doing this would make for very few changes in Core as all the
>> work is done in going from Core to Kernel erlang. We could keep
>> #c_case{}. You would probably not have to change Kernel either, nor
>> the beam as it should be enough with what is there.
>
> Indeed. #c_clause{} is the only candidate for change, really.
> I just wonder how many producers and (especially) consumers of Core Erlang
> there are.
> If it's just the Beam and Hipe compilers that consume Core Erlang, then it's
> at least limited. But I fear there may be analysis tools etc. that would
> have to be taught the new kind of bindings.
>
>> - It would be interesting as it could the left-to-right nature of
>> pattern matching as it is done today. Be more selective in the order
>> you do matching.
>>
>> Robert
>>
>> P.S. Something completely different: the non-determinism in CSP is in
>> the concurrency isn't? I am in the middle of a "discussion" about
>> having a deterministic and defined semantics as opposed to having
>> things undefined and implementation specific. I do have the book
>> somewhere.
>>
>>
>> On 22 April 2012 00:32, Robert Virding <rvirding@REDACTED> wrote:
>> > The actual pattern match compiler does a pretty straight forward
>> > compilation of guards. It the optimiser which does some very weird
>> > things and seems pretty incomprehensible. One though I had when doing
>> > the pattern match compiler was whether we could instead move patterns
>> > in the head explicitly into the guard, have everything there, and work
>> > on that. That would optimise things like type tests in the guard. And
>> > in the case variable binding. There was a paper describing this but I
>> > can't remember it's name or author.
>> >
>> > I would personally like to have variable binding in the guards. I have
>> > a current use for it, so hurry up. :-)
>> >
>> > Robert
>
>