[erlang-questions] List comprehension question

amindfv <>
Thu Jan 16 17:58:45 CET 2014


Or! You can write:

[ A || A = {a, _} <- Foos() ]

Both of these examples work in Haskell also.

Tom


El Jan 16, 2014, a las 11:55,  escribió:

> This is intentional. I use a pattern like this a lot:
> 
> -type foo :: {'a', string()} | {'b', string()}.
> 
> Foos() -> [{a, "hello"}, {b, "goodbye"}].
> 
> As() -> [ S || {a, S} <- Foos() ]. % ["hello"]
> 
> Tom
> 
> 
> El Jan 16, 2014, a las 11:39, Rich Neswold <> escribió:
> 
>> Hello,
>> 
>> This morning I became aware of a (powerful) feature of list
>> comprehensions. Take the following example:
>> 
>>   [ X + Y || {X, Y} <- L].
>> 
>> If we set L to [{1,2}, ok, {1,3}], we get the result [3,4] instead of
>> a pattern match exception (as I was expecting.) This means that list
>> comprehensions give you a "free" lists:filter/2 in the generator
>> expressions!
>> 
>> I've looked through the OTP documentation, quite a few Stack Overflow
>> questions, and several list comprehension tutorials and none of them
>> explicitly state that generator expressions filter elements that don't
>> match their pattern. The web pages emphasize generators and guards are
>> like combinations of lists:map and lists:filter, which isn't exactly
>> correct. For instance, the above example is not the same as:
>> 
>>   lists:map(fun ({X, Y}) -> X + Y end, L).
>> 
>> but is more equivalent to:
>> 
>>   lists:foldr(fun ({X, Y}, Acc) -> [X + Y | Acc];
>>                   (_, Acc) -> Acc
>>               end, [], L).
>> 
>> Is this an expected, but undocumented, feature of list comprehensions?
>> Or am I in "undefined behavior" territory?
>> 
>> --
>> Rich
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list