[eeps] EEP XXX: Pattern-test operator

[Robert Virding]

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. :-)

- If we allowed variable binding in the guard with say Pat = Expr, how
far would this get us?

- 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.

- 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