[erlang-questions] Extensions to comprehensions eeps

[Hynek Vychodil]

On Thu, Jul 31, 2008 at 12:59 PM, Richard Carlsson <richardc@REDACTED>wrote:

> Hynek Vychodil wrote:
>
>> 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.
>>
>>
>> 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]
>>
>> should be same as
>>
>> do_it(Y) -> [X+1, <<X>> <- Y].
>>
>> and deal with it is compiler business.
>>
>
> Most of the time, this is a good principle, but there are trade-offs
> that have to be considered. Each list comprehension expression is
> rewritten by the compiler into a self-recursive function that iterates
> over the input. If you allow the input to be either a list or a binary
> (and the compiler is not able to infer that the input is always a list
> or always a binary), it means that you will have to generate twice as
> much code for each such loop, to handle both cases at runtime. And in
> general, half of that code will never be executed, ever. Some people
> would happily accept this relatively small amount of code bloat, to be
> able to use a single symbol, while some people might not be happy with
> that at all. Separate optimized code paths for float operations have a
> similar trade-off, but currently you only get that if you compile to
> native code.
>
> The other trade-off is that of generality vs. readability and least
> astonishment. For example, should the symbol '+' be overloaded to
> represent every operation that is vaguely "sum"-like? Some languages
> use + both for adding numbers and concatenating lists and strings.
> But then, when you write a function that does both string concatenation
> and adding (maybe on the same line), it can get hard to read, and if the
> language does not do static type checking, and you happen to pass a
> string instead of an integer somewhere, the function will probably
> not crash, but instead start to convert numbers to strings and
> concatenate those strings. If there had been separate symbols for
> the different functions, you would have failed early, and the code
> would (perhaps arguably) have been easier to understand. Separating the
> <=/<- operators in Erlang may not help readability (again, arguably),
> but they do provide early failure if you happen to pass a binary instead
> of a list or vice versa. That might or might not be what you want.
>
>    /Richard
>
> --
>  "Having users is like optimization: the wise course is to delay it."
>   -- Paul Graham
>

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.

-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080731/bad8d76b/attachment.htm>