[eeps] EEP XXX: Pattern-test operator

Erik Søe Sørensen eriksoe@REDACTED
Mon Apr 23 14:09:35 CEST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20120423/5a4b8614/attachment.htm>


More information about the eeps mailing list