[erlang-questions] Compiler list comprehension optimizations
Jonathan Leivent
jleivent@REDACTED
Fri Jun 14 03:38:15 CEST 2013
I have some questions about compiler optimizations on list comprehensions.
The efficiency guide says that list comprehensions that are "neither
assigned to a variable, nor passed to another function, nor returned"
will be optimized by the compiler to avoid the list construction.
However, Dialyzer sometimes complains about such list comprehensions
with "Expression produces a value of type ['ok'], but this value is
unmatched". So I have developed the habit of assigning to "_", as with:
foo(...) ->
...,
_ = [bar(X) || ...],
....
After re-reading that line in the efficiency guide, it seems like this
assignment might actually defeat the above compiler optimization. Does
it? Or does the compiler still manage to do the optimization?
If this does prevent the optimization, is there a way to get the
optimization and prevent the Dialyzer warning while still using a list
comprehension?
Another question about list comprehension optimizations: If a list
being iterated over is generated from a function that just builds the
list element-wise, can the compiler inline that function so that the
intermediate list isn't built? For instance, if the function is
something like the very useful list of all non-empty tails of a list:
alltails(L=[_|T]) -> [L|alltails(T)];
alltails([]) -> [].
[... || T <- alltails(L), ...]
can the compiler generate code that avoids actually building the list of
all tails of L?
Obviously, one could write alltails in (reversed) tail-recursive form,
but I would think that if the compiler has any chance of inlining
alltails into that list comprehension to remove the intermediate list,
the best chance would be with the simpler non-tail-recursive form.
-- Jonathan
More information about the erlang-questions
mailing list