[erlang-questions] List comprehension filter expressions not throwing exceptions

[Richard O'Keefe]

On 4/10/2010, at 10:23 PM, Anthony Shipman wrote:

> On Mon, 4 Oct 2010 03:24:00 pm Richard O'Keefe wrote:
>> 
>> It would be better to be consistent about this.
>> If only bindings Pattern <- Expr and guard tests were allowed,
>> general filters could still be hacked using
>> 	true <- [Boolean_Expression]
>> and everyone would know exactly where they stood.
>> 
> 
> I think it would seriously reduce the usefulness if I couldn't have function 
> calls in the filter tests.

The text you quoted (repeated above) *proved* that it would not
by showing a systematic way to eliminate such ugliness.

I've just checked a bunch of other people's Erlang ocde.

Functions that I saw used in list comprehensions include
 - whereis/1		-- could be allowed in guards
 - member/2		-- could be allowed in guards
 - keymember/3		-- could be allowed in guards

where I'm happy to see them in list comprehensions because I'd be
happy to see them in guards (yes, member/2 takes O(N) time, but
so after all does length/1), plus

 - two that should have been eliminated by better data structure design
 - another that should have been a better algorithm
 - a case where the code would have been half as long had the function
   been inlined, and more efficient as well
 - a case of the form [X || X <- L, X /= f(L), ...]
   which takes quadratic time in its present form, but would have taken
   linear time had it been written FL = f(L), [X || X <- L, X /= FL, ...]
   and is arguably wrong even then
 - several things that could be handled easily by allowing (_;_) in
   list comprehension guards and certainly can be handled with an
   inlined orelse
 - two examples that at first I thought were good ones, but on closer
   inspection could have been handled by better data structure design
   ...

This experience has forced me to two conclusions:

(1) plain function calls in list comprehension filters are generally
    a bad code smell
(2) nested functions in Erlang are also a bad code smell more often
    than not.