When I was checking through <a href="http://trapexit.org">trapexit.org</a> after I had posted my reply I found that in trapexit mr mail had been truncated after the 3rd clause of foo. Did this happen to everyone else as well, a possible gmail bug, or was this only at trapexit, a trapexit bug? We'll see if it gets through uncut into trapexit as quoted text.<br>
<br>Robert<br><br><div><span class="gmail_quote">On 17/03/2008, <b class="gmail_sendername">Robert Virding</b> <<a href="mailto:rvirding@gmail.com">rvirding@gmail.com</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;">
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.<div>
<span class="e" id="q_118bd85cf210cb64_1"><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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br> </blockquote></div>
<br>
</span></div></blockquote></div><br>