[erlang-questions] Compiler list comprehension optimizations

[Jonathan Leivent]

On 06/14/2013 05:16 AM, Thomas Lindgren wrote:
> First, I don't think this is done today.
>
> Second, it's a difficult issue in the general case. Unlike Haskell, Erlang is a strict language, so if you're a stickler for having the program behave the same before and after optimization, you will see that, in the general case, you run a risk of getting different answers if you reorder computations that way. For example, a different exception or different side effects could be generated in the new program. Ensuring the optimization is safe can quickly get intractable to a compiler. (So in practice it might be applied only in rare or simplistic cases.)
>
> With that said, I think it could be interesting to investigate this optimization further, perhaps simply by being more relaxed about such issues. It can obviously yield great results in Haskell.
>
> Best,
> Thomas

OK - I'm trying to develop a feel for when list comprehensions can be 
used to make code more readable without fear that they also might make 
that code slower and/or more wasteful of memory.

I obviously wouldn't want the Erlang compiler to introduce an 
optimization that re-ordered side-effects - I just assumed it would be 
able to tell when functions are side-effect-free in many simple cases 
(and presume that they might have side effects in the more complex cases).

Maybe the particular case of iterating over tails of a list is itself 
useful enough to warrant an addition to the Erlang list comprehension 
syntax - maybe something like:

  [... || Tail <+ List, ...]

That would, for example, make code that generates all 2-combinations of 
elements from a list very easy to read:

  [{X, Y} || [X|Rest] <+ List, Y <- Rest]

One could also imagine a more general case, with an initial expression, 
continue condition, and next expression, kind of like a for loop common 
to other languages:

  [... || I := 0; I < 100; I + 1, ...]

-- Jonathan