[erlang-questions] eep: multiple patterns

[Andras Georgy Bekes]

Hi,

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

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

Example:
1> case a of X when not is_pid(X) -> not_pid end.
not_pid

>   - 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 
negated)!

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

	Georgy