<div dir="ltr"><div>I am not sure I understand your (1): we have been talking about the case where Prefix is bound, just not with a value known at compile time.</div><div><br></div>Of course I noticed the :PrefixSize part, I have been writing about it for 3 emails now. <div>So the :PrefixSize is needed, okay. Why isn't the compiler binding this variable automatically then?</div><div>You know, write:</div><div> <<Prefix/binary, Rest/binary>> = Bla (with Prefix bound)</div><div>and the compiler should generate:</div><div> PrefixSize = byte_size(Prefix),</div><div> <<Prefix:PrefixSize/binary, Rest/binary>> = Bla<br></div><div><br></div><div><div>Obviously the compiler can do this. Now why doesn't it do that already?</div><div>Then, let's implement the same matching for lists.</div><div>And I believe the fact that a list's length is O(n) will not be an issue: you can already pattern match lists today.</div><div><br></div><div>FYI your Haskell example is also a valid Erlang pattern match.</div><div>See <a href="http://erlang.org/doc/reference_manual/expressions.html#id80508">http://erlang.org/doc/reference_manual/expressions.html#id80508</a> section "Expressions in Patterns".</div><div><br></div><div>> Just how much of a problem _is_ this anyway?</div><div><br></div><div>I'm repeating the example I gave before:</div><div><span style="font-size:12.8px"> <<"{", Name/binary, "}">> = PathToken</span><br></div><div>With latest Erlang/OTP (20.1) one has to write:</div><div> <<${, Rest/binary>> = PathToken,</div></div><div> <<$}, Eman/binary>> = binary:reverse(Rest),</div><div> Name = binary:reverse(Eman)</div><div><br></div><div>which wastes copying, creates garbage, is of probably worse complexity and uses a function that doesn't even exist.</div><div>Yes, it is maybe time to add binary:reverse/1, from <a href="https://stackoverflow.com/a/43310493/1418165">https://stackoverflow.com/a/43310493/1418165</a> probably.</div><div><br></div><div>Further improvement to pattern matching:</div><div>How about allowing matching non-local functions?</div><div> case F of</div><div> fun io:format/2 -> blip();</div><div> fun erlang:display/1 -> blop()</div><div> end</div><div>Of course this would only really be matching {M,F,Arity}.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><br></div><div>Cheers,</div><div>-- </div><div>Pierre Fenoll</div></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On 26 October 2017 at 04:47, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 26/10/17 3:11 AM, Pierre Fenoll wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So this can not be described as a pattern.<br>
</blockquote>
<br>
I'm saying let's fix that.<br>
<br>
Prefix ++ Rest as a pattern does not need to be calling ++/2.<br>
Instead, I am suggesting to allow "partial matches": adding support for<br>
these patterns.<br>
What makes this hard? Why is this only sugar?<br>
</blockquote>
<br></span>
(1) Consider Prefix ++ Rest = List where List has N elements.<br>
If Prefix and List are both unbound, there are N+1 solutions.<br>
If List is bound, there is at most one solution.<br>
If Prefix is bound, there is at most one solution.<br>
If Prefix is a list of patterns some of which are unbound,<br>
but the length of Prefix is fixed, there is at most one solution.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why is a similar pattern allowed in binaries but not with lists? (the<br>
<<Prefix:PrefixSize/binary, Rest/binary>> pattern)<br>
</blockquote>
<br></span>
Did you notice the :PrefixSize part? That has to be known.<br>
Otherwise it would have the same multiple-solutions problem.<br>
<br>
(2) "prefix" ++ Rest as a pattern _doesn't_ call ++/2.<br>
It is translated to [$p|[$r|[$e|[$f|[$i|[$x|Rest]]<wbr>]]]]<br>
by the parser. (As noted above, the _elements_ of the list<br>
could perfectly well be any pattern, but the *spine* of the<br>
list must be visibly present.)<br>
<br>
It's rather like the way Haskell used to allow<br>
f 0 = 1<br>
f (n+1) = f n * (n+1)<br>
but did not allow n+m as a pattern.<br>
<br>
<br>
Just how much of a problem _is_ this anyway?<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</div></div></blockquote></div><br></div>