[erlang-questions] Extensions to comprehensions eeps

[Richard Carlsson]

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