[erlang-questions] eep: multiple patterns
Andras Georgy Bekes
Fri May 16 11:10:51 CEST 2008
I am trying to end this discussion with some usable result.
First let me state that
- I am now convinced that ~= is not a good idea, therefore I am not
going to submit it in an eep.
- I am convinced that multiple patterns is a good idea (many of you
stated that you like it). I am about to send it as an eep, we just have
to agree on the right notation.
> Yes, but Virding's proposal uses ";" for the *SAME* meaning
> ("or") that it normally has.
My problem with ; is that it's ambiguous.
I can write at least one pattern that could be parsed into two different
Pattern when Guard; true ->
now is this a single pattern: Pattern when (Guard; true) ?
or is it multiple patterns: (Pattern when Guard); true ?
Both of them are syntactically correct and meaningful as well.
You can convince me that this is no problem, the new use of ; will not
introduce any confusion, but I am aware.
I think using a new operator is better.
> that "|" is already a very important symbol in Erlang with about
> as different a meaning
I think "|" in this context is not confusable with [_|_], but maybe yes.
Can anyone suggest another operator?
Now I'll answer to a few other thoughts. I am trying to reply to only
those where I hope my answer might take Erlang forward.
> The multiple pattern proposal makes patterns even MORE complicated,
> without naming them, so a human being reading one has to do an
> immense amount of decoding to figure out what the pattern *means*.
> If there are several places where you need (basically) the same
> complex pattern, too bad: you have to write the thing out in full
> each time because you can't NAME it and use it more than once.
> This is a disaster for maintenance, because it is far too easy to
> change *some* of the occurrences of the pattern and not others.
I have seen pieces of code when multiple patterns (as in my proposal)
could have been used, but have not seen a single case when the same
multiple pattern occured in several places.
> Abstract patterns let you name patterns (simple, complex, or already
> in the first proposal, MULTIPLE) and use them whenever you want.
I think the use of abstract patterns for what I suggest multiple
patterns for leads to lengthy extra code that is unnecessary.
However, abstract patterns are great for other uses, but not for this
very simple thing.
> > You can't negate it!
> Who says? According to the current on-line Erlang reference
> manual, you can't negate *anything* in a guard,
>From the Reference Manual: "The set of valid guard expressions...
... arithmetic expressions...".
1> case a of X when not is_pid(X) -> not_pid end.
> - allowing = in guards is *always* more powerful than adding ~=
> - there is no reason why = in a guard cannot be negated,
> if there is anything in a guard that can be negated.
I agree. If you can negate it, it is clearly better than what I
suggested with ~=. What would be the syntax and semantics?
It would stink because of the same problem of not binding variables (if
> I also repeat what I've been saying all along, which is that
> the abstract pattern proposal has been around for a long time, and
> keeps on turning out to be just right for new problems.
OK, as I said before, I am convinced that your abstract patterns are
great, but when will the eep be ready?
More information about the erlang-questions