<div dir="ltr"><br><div class="gmail_quote">On Thu, Jul 31, 2008 at 12:05, Hynek Vychodil <span dir="ltr"><<a href="mailto:vychodil.hynek@gmail.com">vychodil.hynek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div><div></div><div class="Wj3C7c"><br><div class="gmail_quote">On Thu, Jul 31, 2008 at 9:59 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="gmail_quote">2008/7/31 Hynek Vychodil <span dir="ltr"><<a href="mailto:vychodil.hynek@gmail.com" target="_blank">vychodil.hynek@gmail.com</a>></span><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div dir="ltr">There is functional difference, between <- and <= is not functional difference.<br>There is not reason why<br>[X || <<X>> <- <<"abc">> ].<br>
should not return same result as<br> > [X || <<X>> <= <<"abc">> ].<br>"abc"<br></div></blockquote></div><div><br>Hi,<br><br>I might be mistaken here, but I think the issue is that the compiler generates completely different code for each case and when the generator looks like X <- Y, i.e. the right side is not a constant, it has to know which one to produce. The compiler can't guess from the source code, because for example <<X>> <- L is a very normal list generator, one can't assume L is a binary.<br>


<br>best regards,<br>Vlad<br><br></div></div></div>
</blockquote></div><br></div></div>I understand it, but I think this is wrong design decision. Compiler optimization should not impact language design, especially in so clear functional language as Erlang is. {joke, "It should not evolve in ugliness of assembly language"}. For example, in some lisp compilers, I heard, are two entry point to function, with and without parameters check and so. And HiPE do some optimization for float only functions ... This is better way how deal with it. Changing language to solve some special low level optimizations is wrong idea.<br>

<br>do_it(L) when is_list(L) -> [X+1, <<X>> <- L];<br>do_it(B) when is_binary(B) -> [X+1, <<X>> <- B]. % [X+1, <<X>> <= B]<br><br>should be same as<br><br>do_it(Y) -> [X+1, <<X>> <- Y].<br>

<br>and deal with it is compiler business.<br></div></blockquote></div><br>Not quite. Compare these<br>7> [X || <<X,X>> <= <<1,2,2,3,4,4,5,6>>].<br>[4]<br>8> [X || [X,X] <- [1,2,2,3,4,4,5,6]].  <br>
[]<br>9> [X || [X,X] <- [[1,2],[2,3],[4,4],[5,6]]].  <br>
[4]<br>
<br>With binary comprehensions you are not limited to matching one element at a time (like you are with lists), so there is a functional difference.<br><br>10> [{X,Y} || <<X,Y>> <= <<1,2,2,3,4,4,5,6>>].<br>
[{1,2},{2,3},{4,4},{5,6}]<br><br>best regards,<br>Vlad<br><br></div>