[erlang-questions] In praise of Erlang's 'if'

[Anthony Ramine]

I just made a pull request for cond expressions:

	https://github.com/erlang/otp/pull/464

Regards,

-- 
Anthony Ramine

Le 21 août 2014 à 10:37, Anthony Ramine <n.oxyde@REDACTED> a écrit :

> Hello Richard,
> 
> Then, let’s assume the user wants to finally use guard disjunctions in if clauses:
> 
>  if     Green,     Crispy                    -> steam()
>   ;     Green, not Crispy                    -> chop()
>   ; not Green;               Leafy,   Hard   -> fry(), grill()
>   ; not Green,               Leafy, not Hard -> fry(), boil()
>   ; not Green,           not Leafy           -> fry(), bake()
>  end
> 
> Now you have a guard disjunction quite hidden in the middle of a guard, and it’s tolerable only with your nonstandard indentation scheme, because in real life here is what happens:
> 
> 	https://github.com/tuncer/rebar/commit/2c4d7d1d9bdc2a11d3f485f844500bf4c2aa77a2
> 
> Since that design flaw (which is what it is to my eyes) of the Erlang syntax was demonstrated to me, I want guard sequences to be deprecated in ‘if’ clauses’ heads. Or maybe ‘if’ in its entirety, replaced by ‘cond’, if I want to be fancy.
> 
> Regards,
> 
> -- 
> Anthony Ramine
> 
> Le 21 août 2014 à 05:21, Richard A. O'Keefe <ok@REDACTED> a écrit :
> 
>> Erlang's 'if' is often criticised, so I thought it would
>> be nice to show an example where it's just right.
>> 
>> In connection with the recent thread on Potion,
>> I've been re-reading
>>   Visual Programming Languages and the
>>   Empirical Evidence For and Against
>>   K.N.Whitley, October 1996,
>>   submitted to the Journal of Visual Languages and Computing.
>> 
>> Amongst other evidence for visual programming languages, this
>> paper cites Scanlan's "Structured flowcharts outperform
>> pseudocode: An experimental comparison", IEEE Software, June 1989.
>> Scanlan's article is, it seems to me, a classic case of
>> claiming too much.  The title suggests, and the text clearly
>> states, that 'structured flowcharts' are superior to 'pseudocode',
>> where what was established was that one particular form of
>> flowchart was superior to one particular form of pseudocode.
>> 
>> Here's one of the pseudo-code examples:
>> 
>>  IF GREEN
>>     THEN
>>        IF CRISPY
>>           THEN
>>              STEAM
>>           ELSE
>>              CHOP
>>        ENDIF
>>     ELSE
>>        FRY
>>        IF LEAFY
>>           THEN
>>              IF HARD
>>                 THEN
>>                    GRILL
>>                 ELSE
>>                    BOIL
>>              ENDIF
>>           ELSE
>>              BAKE
>>        ENDIF
>>  ENDIF
>> 
>> The weird layout is none of my invention.
>> Now, suppose we used Erlang as the pseudocode:
>> 
>> 
>> 
>>  if     Green,     Crispy                    -> steam()
>>   ;     Green, not Crispy                    -> chop()
>>   ; not Green,               Leafy,   Hard   -> fry(), grill()
>>   ; not Green,               Leafy, not Hard -> fry(), boil()
>>   ; not Green,           not Leafy           -> fry(), bake()
>>  end
>> 
>> How do you think the comparison would have come out then?
>> 
>> There is an old experiment that showed that
>> if X ... ifnot X ... end
>> was easier to understand than if X ... else ... end, and
>> oddly enough the 'hungry hare' examples in Scanlan appear
>> to have been taken from it, without learning its lesson.
>> It is at least possible that Scanlan's results were entirely
>> due to this factor, not the 'visual' aspect per se.)
>> 
>> The irony is that an Erlang 'if', laid out the way I've
>> laid it out, would in Whitley's paper have been classified
>> as a 'visual' notation (subclass 'matrix').
>> 
>> We could also do it as a 'case':
>> 
>>  case {Green, Crispy, Leafy, Hard }
>>    of {true,  true,   _,     _    } -> steam()
>>     ; {true,  false,  _,     _    } -> chop()
>>     ; {false, _,      true,  true } -> fry(), grill()
>>     ; {false, _,      true,  false} -> fry(), boil()
>>     ; {false, _,      false, _    } -> fry(), bake()
>>  end
>> 
>> but in this case I think 'if' is easier to read.
>> 
>> You might want to object that Scanlan could not have been
>> expected to think of this kind of layout in 1986, but this
>> is just a 'decision table', and decision tables are much
>> older than that and were well known in the 70s.
>> 
>> What this illustrates above all is that proving that some
>> particular language or language feature is better or worse
>> than some other can be much harder than you think, and
>> that even classic results in the field can collapse under
>> a little inspection.
>> 
>> 
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>