[erlang-questions] eep: multiple patterns

Andras Georgy Bekes <>
Thu May 15 13:07:18 CEST 2008


Hi,

> I feel that this proposal is a step in the wrong direction,
> and has "hack" written all over it.
I agree with some of what you've written, but you completely missed one 
very important detail.

> Let's start with the pattern-match operator,
It seems to me you also finished with the pattern-match operator.
The other part of the eep (multiple patterns) is OK?

> 	1 = f()
> but I cannot do
> 	(X when X > 1) = f()
I completely agree. Whe should be able to do the latter, however, I 
don't consider it important.

> ~= is only useful because = is not allowed in guards.
>
> So instead of adding a new "crippled-bind" called ~=,
> I suggest that it would be better to allow
> Pattern = Expression as a guard.
You can't negate it!

I've also written, I think the most important use of the ~= operator was 
to express negated patterns, i.e. the ability to write a guard that 
fails if (some part of) the matched value matches a pattern. It seems 
you completely missed this point.

> What about the intended uses of ~= where the fact that
> it does not bind variables is important?
If it doesn't match, it naturally can't bind variables.
That's it.

Please propose a different construct that expresses negated patterns, 
and is easy to implement, understand and use. I told you I am 
dissatisfied with what I'm about to propose, I just can't find a better 
solution.

> I don't like vague suggestions that
> "It is rather common to check the value of an expression with a
>      case expression and do the same actions in some of the cases."
> I want to see *actual cases*.
I think I am not allowed to copy-paste code pieces from AXD301 here.
Beleive me, I could.
Do you want me to obfuscate and send a few?

> Oh, and did I point out that abstract patterns can solve the
> "multiple patterns" problem neatly and clearly?
I accept your abstract patterns as useful and nice, but is quite a big 
change in the language. My proposal is a small change. Easy to learn, 
easy to implement, easy to document, no compatibility issues.

	Georgy



More information about the erlang-questions mailing list