[eeps] EEP XXX: Pattern-test operator

Michael Truog <>
Mon Apr 16 03:05:50 CEST 2012

On 04/15/2012 05:53 PM, Richard O'Keefe wrote:
> 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
So you believe that pattern matching in guards requires binding local variables to be useful, right?  You do not seem to be concerned about this change causing guards to create side-effects, where they previously where unable to do so.  Are we just not aware or recognizing any potential negative aspects of binding variables within guard statements, or do we just accept them as a necessary evil?  To me, the idea of guard statements binding variables seems to contradict both the purpose/name "guard" since it is guarding state, and binding a variable within the guard statement would be allowing the state to leak out.

I don't want to push this point if it isn't regarded as a problem, but I just wanted to understand how you see it.


More information about the eeps mailing list