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:<br>
<br>foo(Pat11, ...) when Guard1 ;<br>foo(Pat12, ...) when Guard2 ;<br>foo(Pat13, ...) when Guard3 -><br>    ...;<br>etc.<br><br>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:<br>
<br>case ... of<br>    Pat1 when Guard1 ;<br>    Pat2 when Guard2 -> ...;<br>    ...<br>end<br><br>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.<br>
<br>I remember that Richard's abstract patterns would also do this but here it would just be more explicit and dynamic.<br><br>Robert<br><br>* 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.<br>
<br><br><div><span class="gmail_quote">On 17/03/2008, <b class="gmail_sendername">Andras Georgy Bekes</b> <<a href="mailto:bekesa@sch.bme.hu">bekesa@sch.bme.hu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> But now consider<br> ><br> >       f({X,_}\/{_,X},<br> >         {Y,X}\/{X,Y},<br> >         ...<br> >         {Z,W}\/{W,Z}<br> >       )<br> <br>So matching this pattern must involve backtracking. Awww.<br>
 <br><br> > You could hack around this by requiring that if a head variable is<br> > bound in a disjunctive pattern it is not matched by any other head<br> > pattern.<br> <br>The problem does exist in a single pattern:<br>
 <br>         {{X,_}\/{_,X},<br>          {Y,X}\/{X,Y},<br>          ...<br>          {Z,W}\/{W,Z}}<br> <br> <br>We could of course generalise the above restriction, but it doesn't make<br> it tolerable.<br> <br> But what are the real problems with the search for the right match with<br>
 backtracking? If the programmer has written that silly pattern, he/she<br> should be aware that it might not be very fast. Are there consequences<br> other than the match being slow?<br> <br><br> > I note that my abstract pattern proposal *already* gives you<br>
 > disjunctive patterns, BUT in such a way that the disjunctions can't<br> > interact like this.<br> <br>Could you give some reference?<br> I've searched for "abstract pattern" in the archives and found a few<br>
 mail, but not your paper.<br> <br><br>        Georgy<br> <br>_______________________________________________<br> erlang-questions mailing list<br> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
 <a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br> </blockquote></div><br>