[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

[Anthony Ramine]

Err, sorry again Jonathan.

Forwarding to list.

-- 
Anthony Ramine

Le 21 juin 2013 à 02:33, Anthony Ramine a écrit :

> Indeed, sorry.
> 
>> OK - so you just blew my mind.  What is happening here?  Let me see if I can explain it:
>> 
>> In F, the "X rem 2" guard fails because X is not an integer - but it is in a guard context, so no error is produced, the guard just evaluates to false, and F([foo]) returns [].
>> 
>> In G, the "X rem 2" is in the rhs of an "assignment" - really a match expression: that is no longer a guard context, so G([foo]) produces an error instead.
>> 
>> Does that sound right?
> 
> Indeed, a match is an expression which is not a guard, thus the filter is compiled with expression semantics.
> 
>> Personally, I would stay away from using this false-not-error-on-bad-type behavior of guards that are not patterns. It's easy enough to use the is_type BIFs to make the meaning explicit and far less astonishing:
>> 
>> H = fun (L) -> [X || X <- L, is_integer(X), X rem 2 =:= 0] end.
>> 
>> But, then I'm writing Erlang code that I expect to be read and understood by non-Erlang programmers.
>> 
>> Is Dialyzer (or some other lint-like Erlang tool) customizable?  If so, I'd like to add a customization that flags such cases for my own use.
> 
> What could be done is to compile every filter as an expression and introduce a new kind of expression, something like "when Guard end", which would compile Guard with guard semantics.
> 
> What's good:
> 
> Guard semantics usable everywhere, with full power and disjunction and conjunctions, something not doable in current comprehensions.
> 
> Syntax clues about what has guard semantics and what has expression semantics.
> 
> What's bad:
> 
> Breaking backwards compatibility. Huge problem. So huge I wouldn't be surprised and I would rather expect that the semantics comprehension filters will never change.
> 
> Nevertheless, I do think it is feasible in multiple OTP versions, progressively.
> 
> Regards,