[erlang-questions] eep: multiple patterns
Andras Georgy Bekes
bekesa@REDACTED
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