<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Nice try.<div><br></div><div>/Tony</div><div><br><div style=""><div>On 1 sep 2014, at 19:28, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com">n.oxyde@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I just made a pull request for cond expressions:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/erlang/otp/pull/464">https://github.com/erlang/otp/pull/464</a><br><br>Regards,<br><br>-- <br>Anthony Ramine<br><br>Le 21 août 2014 à 10:37, Anthony Ramine <n.oxyde@gmail.com> a écrit :<br><br><blockquote type="cite">Hello Richard,<br><br>Then, let’s assume the user wants to finally use guard disjunctions in if clauses:<br><br> if Green, Crispy -> steam()<br> ; Green, not Crispy -> chop()<br> ; not Green; Leafy, Hard -> fry(), grill()<br> ; not Green, Leafy, not Hard -> fry(), boil()<br> ; not Green, not Leafy -> fry(), bake()<br> end<br><br>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:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>https://github.com/tuncer/rebar/commit/2c4d7d1d9bdc2a11d3f485f844500bf4c2aa77a2<br><br>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.<br><br>Regards,<br><br>-- <br>Anthony Ramine<br><br>Le 21 août 2014 à 05:21, Richard A. O'Keefe <ok@cs.otago.ac.nz> a écrit :<br><br><blockquote type="cite">Erlang's 'if' is often criticised, so I thought it would<br>be nice to show an example where it's just right.<br><br>In connection with the recent thread on Potion,<br>I've been re-reading<br> Visual Programming Languages and the<br> Empirical Evidence For and Against<br> K.N.Whitley, October 1996,<br> submitted to the Journal of Visual Languages and Computing.<br><br>Amongst other evidence for visual programming languages, this<br>paper cites Scanlan's "Structured flowcharts outperform<br>pseudocode: An experimental comparison", IEEE Software, June 1989.<br>Scanlan's article is, it seems to me, a classic case of<br>claiming too much. The title suggests, and the text clearly<br>states, that 'structured flowcharts' are superior to 'pseudocode',<br>where what was established was that one particular form of<br>flowchart was superior to one particular form of pseudocode.<br><br>Here's one of the pseudo-code examples:<br><br> IF GREEN<br> THEN<br> IF CRISPY<br> THEN<br> STEAM<br> ELSE<br> CHOP<br> ENDIF<br> ELSE<br> FRY<br> IF LEAFY<br> THEN<br> IF HARD<br> THEN<br> GRILL<br> ELSE<br> BOIL<br> ENDIF<br> ELSE<br> BAKE<br> ENDIF<br> ENDIF<br><br>The weird layout is none of my invention.<br>Now, suppose we used Erlang as the pseudocode:<br><br><br><br> if Green, Crispy -> steam()<br> ; Green, not Crispy -> chop()<br> ; not Green, Leafy, Hard -> fry(), grill()<br> ; not Green, Leafy, not Hard -> fry(), boil()<br> ; not Green, not Leafy -> fry(), bake()<br> end<br><br>How do you think the comparison would have come out then?<br><br>There is an old experiment that showed that<br>if X ... ifnot X ... end<br>was easier to understand than if X ... else ... end, and<br>oddly enough the 'hungry hare' examples in Scanlan appear<br>to have been taken from it, without learning its lesson.<br>It is at least possible that Scanlan's results were entirely<br>due to this factor, not the 'visual' aspect per se.)<br><br>The irony is that an Erlang 'if', laid out the way I've<br>laid it out, would in Whitley's paper have been classified<br>as a 'visual' notation (subclass 'matrix').<br><br>We could also do it as a 'case':<br><br> case {Green, Crispy, Leafy, Hard }<br> of {true, true, _, _ } -> steam()<br> ; {true, false, _, _ } -> chop()<br> ; {false, _, true, true } -> fry(), grill()<br> ; {false, _, true, false} -> fry(), boil()<br> ; {false, _, false, _ } -> fry(), bake()<br> end<br><br>but in this case I think 'if' is easier to read.<br><br>You might want to object that Scanlan could not have been<br>expected to think of this kind of layout in 1986, but this<br>is just a 'decision table', and decision tables are much<br>older than that and were well known in the 70s.<br><br>What this illustrates above all is that proving that some<br>particular language or language feature is better or worse<br>than some other can be much harder than you think, and<br>that even classic results in the field can collapse under<br>a little inspection.<br><br><br><br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote><br></blockquote><br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">"Installing applications can lead to corruption over time. </span><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">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"</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; "><br></span></div></span><br class="Apple-interchange-newline">
</div>
<br></div></body></html>