[erlang-questions] eep: multiple patterns

[Robert Virding]

Sorry for taking so long to comment this, but I have been thinking. :-)
Comments follow.

2008/5/16 Mats Cronqvist <mats.cronqvist@REDACTED>:

> Andras Georgy Bekes wrote:
> > 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.
>

Here I disagree, sort of. While I also think the ~= is not a good idea, I
agree with Richard O'Keefe that having = as a legal guard test is a Good
Thing. I also don't see any logical problems with it. If you have the
semantics:

- if match succeeds it returns true and binds any unbound variables
- if match fails, it returns false, i.e. it does generate an error

Then you modify all boolean operations so that if they succeed, return true,
then any new variables which are bound in them are exported, while if they
fail, return false, no variables are exported.

- This will work for the whole guard as if the guard fails then no variables
are exported but the clause is not chosen anyway.
- No problems with not(...) as it will never export variables.
- Same with other boolean operators, success implies export. This makes
checking for variable bindings in and after guards relatively easy.

As far as I can see there are no problems with this.

Then as we allow = as a boolean test in guards we can extend it to be a
valid *test* in list/binary comprehensions as well. It the match succeeds
the test succeeds and exports the any new variable bindings. Someone asked
for this earlier and while just having it in lc/bc might be a bit off having
it as a valid *guard* test means it becomes acceptable as lc/bc test. It
also easy to implement. I have the this feature already in LFE.

> - 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 ?
>  i was reading virding's proposal as;
>
> case bla of
>  Pat when true ->;
>  Pat when false->;
>  Pat ->
>    code()
> end.
>
>  but that's not what he wrote...
>
>  in that case i propose the above. currently gives syntax error.
>

I don't have a problem with this, but I don't really see the need. The only
time I have had repeated bodies they have been very simple no repeating just
them has been very straight forward. While using ->; as syntax would be easy
and cause no inconsistencies it has the downside that you would fail to
capture the case where you have forgotten to give a body.

Actually thinking about it a bit more if you allow = in guards you really
don't *need* this multiple pattern feature as you can express it as
alternate guards. The problem would be that it would be more difficult to
implement this pattern matching as efficiently as when it occurs the the
head.

So maybe this solves the syntax question automatically.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080523/62ac2de0/attachment.htm>