<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 31, 2008 at 12:59 PM, Richard Carlsson <span dir="ltr"><<a href="mailto:richardc@it.uu.se">richardc@it.uu.se</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;">
Hynek Vychodil wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I understand it, but I think this is wrong design decision. Compiler optimization should not impact language design, [...] Changing language to solve some special low level optimizations is wrong idea.<div class="Ih2E3d">
<br>
<br>
<br>
do_it(L) when is_list(L) -> [X+1, <<X>> <- L]; 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>
<br>
Most of the time, this is a good principle, but there are trade-offs<br>
that have to be considered. Each list comprehension expression is<br>
rewritten by the compiler into a self-recursive function that iterates<br>
over the input. If you allow the input to be either a list or a binary<br>
(and the compiler is not able to infer that the input is always a list<br>
or always a binary), it means that you will have to generate twice as<br>
much code for each such loop, to handle both cases at runtime. And in<br>
general, half of that code will never be executed, ever. Some people<br>
would happily accept this relatively small amount of code bloat, to be<br>
able to use a single symbol, while some people might not be happy with<br>
that at all. Separate optimized code paths for float operations have a<br>
similar trade-off, but currently you only get that if you compile to<br>
native code.<br>
<br>
The other trade-off is that of generality vs. readability and least<br>
astonishment. For example, should the symbol '+' be overloaded to<br>
represent every operation that is vaguely "sum"-like? Some languages<br>
use + both for adding numbers and concatenating lists and strings.<br>
But then, when you write a function that does both string concatenation<br>
and adding (maybe on the same line), it can get hard to read, and if the<br>
language does not do static type checking, and you happen to pass a<br>
string instead of an integer somewhere, the function will probably<br>
not crash, but instead start to convert numbers to strings and<br>
concatenate those strings. If there had been separate symbols for<br>
the different functions, you would have failed early, and the code<br>
would (perhaps arguably) have been easier to understand. Separating the<br>
<=/<- operators in Erlang may not help readability (again, arguably),<br>
but they do provide early failure if you happen to pass a binary instead<br>
of a list or vice versa. That might or might not be what you want.<br>
<br>
    /Richard<br><font color="#888888">
<br>
-- <br>
 "Having users is like optimization: the wise course is to delay it."<br>
   -- Paul Graham<br>
</font></blockquote></div><br>OK, you are right. '+' numbers vs string operations is good example. Erlang is not typeless language it is not strong typed only. There is good reason why distinct between <- and <= as different typed operands. As another example 'true and false' vs '1 band 2'. There are many such kinds in current Erlang.<br clear="all">
<br>-- <br>--Hynek (Pichi) Vychodil<br>
</div>