[erlang-questions] Tried this... Thought it interesting... But it didn't work.

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Tue Sep 1 20:01:38 CEST 2015

On Tue, Sep 1, 2015 at 6:43 PM, zxq9 <zxq9@REDACTED> wrote:

> Honestly, I don't really think this is the best use of list comprehension
> syntax. I can easily imagine people being confused at that, or at least
> requiring a few moments thought to figure out wtf is going on in that line.
> The fact this confounded you (and the example was unclear in the blog post,
> imo) is a good reason why you shouldn't do this in your code.

I must admit I sometimes do this. Consider:

f(X) ->
    E = case X > 5 of
        true -> [7];
        false -> []
    [1,2,3] ++ E ++ [4,5].

This is easier written as

f(X) ->
   [1,2,3] ++ [7 || X > 5] ++ [4,5].

but as a way to get the list comprehension to append like this is the only
way I tend to use the construction. For real-world use, consider the
following snippet from my Maps R18 tests:


remove_args(#state { contents = C } = State) ->
      [{5, ?LET(Pair, elements(C), [element(1, Pair)])} || C /= [] ] ++
      [{1,  ?SUCHTHAT([K], [map_key(State)], find(K, 1, C) == false)}]).

The idea here is that we want to generate arguments for removing an element
from a map, and C contains the current contents of the map. If the map is
non-empty, C /= [], and we can pick elements from C. Otherwise, we generate
a map key such that it is really not an element of the map in question
(which is trivially true if C = []). The neat part is that the first
variant with frequency 5 is never generated for the empty map.

A case analysis in this case would tend to repeat code, so I find this
somewhat more nimble. But these situations are probably the only situations
on which I use this way of writing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150901/eb074479/attachment.htm>

More information about the erlang-questions mailing list