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

[Anthony Ramine]

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