[erlang-questions] The If expression

[John Hughes]

I use a list comprehension when I need a one armed if with a side  
effect.

[io:format("Values: ~p\n",[Vs]) || Vs/=[]]

Looks funny at first but you soon get used to it.

John

Sent from my iPhone

On 28 May 2010, at 03:20, Henning Diedrich <hd2010@REDACTED> wrote:

> I think I found my one-armed-if at long last!
>
> Shame on everybody standing by who knew it all along and chuckled  
> with glee:
>
>           Index /= null orelse throw(index_null).
>
>
> *love it* *beautiful* *ouch* *ey! stop that!*
>
> I am still trying hard to avoid the need for a one armed if as per  
> the reasons brought up in this thread.
>
> Many times I succeed and the extra effort pays off in a yet better  
> understanding of the FP ways.
>
> However, whenever the desire is for more informative error messages  
> --- over 'just let it crash' --- anything else clutters the code and  
> one-armed ifs *are* the right thing to use there because I don't  
> care for all the other cases. In such cases I am not interested in  
> what value may be returned because I will break away anyway.
>
> And better error messages are a legitimate constraint sometimes. I  
> understand it's not in Erlang's heritage in some way.
>
> Message passing and IO are other areas where side effects are the  
> focus, not return values. And where therefore one-armed ifs could be  
> a honest thing.
>
> From all the help, which I want to say *thank you* for, the  
> following had been the strongest advice that stuck with me in its  
> simplicity and fair abstraction:
>
> Robert Virding wrote:
>> ... however you choose to use 'if', or any other
>> construction for that matter, Erlang is a functional language and
>> everything returns, and must return, a value.
> Thanks, Robert, this reminder helped to get into the right thinking  
> often times!
>> So even if 'if' didn't
>> need to have an explicit default or else case then it would still  
>> have
>> to return a value. We would never be able agree on a default value
>> anyway. :-) 'nil' is not a good value here as it has no inherent
>> meaning in Erlang as it does in Lisp.
>>
> It probably held true 80% of the times when I ran into a subjective  
> (<- qualifier inserted for Rich!) need of a one-armed-if.
>
> But whenever exceptions come into play, the return value argument  
> can become mute I found, in FP. As suggested by the fact that the  
> result of the after-body of try-catch-after constructs are discarded  
> as well. Currently I'd argue that in an analogous way the second arm  
> of 'case' or 'if' is not necessarily-necessary when the only arm  
> that matters is ending on  throw/erlang:error/exit. If I wisen up, I  
> promise I'll retract.
>
> I did find very many occasions where instead of a 'case', the  
> correct pattern matching in the function head made all the  
> difference, or a 'case' structure could with some deliberation be  
> rewritten to have a sensical second arm.
>
> But especially when I need to throw an error /from/ a place 'higher  
> up' in the call stack to put more information with it, I couldn't  
> always find a sensible way to use the second arm of and 'if' or  
> 'case'. (Re throwing from higher up: e.g. a list may have been  
> consumed in its entirety 'lower down' when I realize a dead end is  
> hit. And so I can't show it in the error message if it's thrown from  
> there. Unless I add a parameter.)
>
> Thank you again for all your thoughts, they are very much appreciated.
>
> Henning