[erlang-questions] erlang *****

Robert Virding rvirding@REDACTED
Mon Mar 17 17:15:05 CET 2008

One thing that has to be considered in this discussions are guards. Guards
are, irrespective of how some people would like to view them, part of
pattern matching but those bits which can be difficult to express in a
pattern*. As the guard varies with the pattern then they have to be kept
together, something like:

foo(Pat11, ...) when Guard1 ;
foo(Pat12, ...) when Guard2 ;
foo(Pat13, ...) when Guard3 ->

Having no "-> Body" after the pattern/guard means that you share the same
body as the following clauses down to a clause with a body. In case/receive
it would look something like:

case ... of
    Pat1 when Guard1 ;
    Pat2 when Guard2 -> ...;

This is just a suggestion to both include patterns, which you must, and not
introduce any new syntax. It also looks a bit more Erlangy. I haven't tried
modifying the parser but it will probably need modification of the AST. I
don't think there would be any problems in compiling this, or an equivalent.

I remember that Richard's abstract patterns would also do this but here it
would just be more explicit and dynamic.


* I have seen attempts to bake in guard tests into patterns but I think they
become largely unreadable and manage to effectively hide the actual pattern.

On 17/03/2008, Andras Georgy Bekes <bekesa@REDACTED> wrote:
> > But now consider
> >
> >       f({X,_}\/{_,X},
> >         {Y,X}\/{X,Y},
> >         ...
> >         {Z,W}\/{W,Z}
> >       )
> So matching this pattern must involve backtracking. Awww.
> > You could hack around this by requiring that if a head variable is
> > bound in a disjunctive pattern it is not matched by any other head
> > pattern.
> The problem does exist in a single pattern:
>          {{X,_}\/{_,X},
>           {Y,X}\/{X,Y},
>           ...
>           {Z,W}\/{W,Z}}
> We could of course generalise the above restriction, but it doesn't make
> it tolerable.
> But what are the real problems with the search for the right match with
> backtracking? If the programmer has written that silly pattern, he/she
> should be aware that it might not be very fast. Are there consequences
> other than the match being slow?
> > I note that my abstract pattern proposal *already* gives you
> > disjunctive patterns, BUT in such a way that the disjunctions can't
> > interact like this.
> Could you give some reference?
> I've searched for "abstract pattern" in the archives and found a few
> mail, but not your paper.
>         Georgy
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080317/02dd1272/attachment.htm>

More information about the erlang-questions mailing list