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

[Tony Rogvall]

Nice try.

/Tony

On 1 sep 2014, at 19:28, Anthony Ramine <n.oxyde@REDACTED> wrote:

> 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
>> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140901/9daf4f9b/attachment.htm>