<br><br><div class="gmail_quote">On Fri, Jan 23, 2009 at 3:54 AM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 2 Jan 2009, at 9:14 am, Fredrik Svahn wrote:<br>
> In addition to the above (which is kept for backwards compatibility) I<br>
> suggest adding an alternative form with the following syntax:<br>
><br>
> if Expression -> Body else -> ElseBody end<br>
><br>
> which should act as syntactical sugar for the more clumsy and<br>
> unintuitive:<br>
><br>
> case Expression of<br>
> true -> Body;<br>
> _Else -> ElseBody<br>
> end<br>
><br>
</div>I'm sorry for the late reply, but December/January is the<br>
long holiday in New Zealand, and I only got back yesterday.<br>
<br>
This is a very bad idea because<br>
- It would give us two very *different* conditional structures<br>
with the *same* keyword, where it is hard to tell which one<br>
was intended until several lines later.<br>
<br>
- 'if' isn't actually all that rare. In some code I wrote last<br>
year, I find one 'if' for every four 'case's. The OTP sources<br>
have 1 if/10 case, which is less common, but not _that_ rare.<br>
If the old sense of 'if' were rare, we could probably live with<br>
the confusion.<br>
<br>
- The new syntax is not consistent with Erlang "style", which<br>
expects multiple arms as a matter of routine (like the Fortran,<br>
Ada, Eiffel, Algol 68 "block if" constructs, but without an "else").<br>
<br>
- As a result the new syntax is rather inconvenient. The majority<br>
of my existing uses of 'if' have more than one arm, so would need<br>
nested new-'if's. It's hard to see that as an improvement.<br>
<div class="Ih2E3d"><br>
<br>
> My hope is that with this improvement 'if'-statements would be the<br>
> recommended choice for expressions evaluating to a bool()<br>
<br>
</div>It would not be an improvement.<br>
Such expressions should be avoided, not canonised.<br>
<div class="Ih2E3d">> The proposal would address two of the problems with the current<br>
> syntax:<br>
><br>
> 1. Today only guards are allowed, not full expressions. For instance,<br>
> today it is NOT ok to write:<br>
><br>
> if erlang:system_info(smp_support) -> init_smp();<br>
> true -> init()<br>
> end.<br>
><br>
> which many believe is a rather serious limitation of the usefulness.<br>
<br>
</div>And many don't. In fact this is an excellent example of what's<br>
wrong with Boolean functions. The interface *should* have been<br>
something like<br>
<br>
case erlang:system_info(smp)<br>
of not_supported -> ...<br>
; supported -> ...<br>
end<br>
<br>
and other values are imaginable: smp support might have been compiled<br>
in, but not actually useful because only one core is available. So<br>
maybe the interface should have been<br>
<br>
case erlang:system_info(smp)<br>
of not_supported -> ...<br>
; interfaces_supported -> ...<br>
; functional_and_useful -> ...<br>
end<br>
<br>
Indeed, if I wanted to know whether to set up for SMP, I would<br>
probably use system_info(multi_scheduling) instead:<br>
<br>
case erlang:system_info(multi_scheduling)<br>
of disabled -> no SMP or only one scheduler<br>
; blocked -> there are multiple schedulers and all<br>
but one of them are blocked<br>
; enabled -> multiple schedulers are really available<br>
end<br>
<br>
About 40 years ago when enumeration types were introduced it<br>
was pointed out that people over-used Boolean. I've been guilty<br>
of that myself. In Erlang, our aim is to write reliable and<br>
maintainable software. We shouldn't regard it as a PROBLEM<br>
that Boolean expressions are hard to use, we should regard it<br>
as a heaven-sent OPPORTUNITY to critically, and I really do mean<br>
SERIOUSLY critically review all uses of Boolean to see whether<br>
they are really appropriate. My own experience is that in the<br>
majority of cases they are not. (My use of 'if' is almost<br>
entirely arithmetic comparisons.)<br>
<div class="Ih2E3d"><br>
> 2. At least of of the guards have to evaluate to true, otherwise a<br>
> runtime error will occur. This leads to unintuitive constructs like:<br>
><br>
> if Bool -> do_true();<br>
> true -> do_false() end.<br>
><br>
> Which could be replaced by a more intuitive:<br>
><br>
> if Bool -> do_true() else -> do_false() end.<br>
<br>
</div>It may be more FAMILIAR, but that doesn't mean 'else' is a good<br>
thing. I know that writing '; true ->' is a very easy way to get<br>
'else' in Erlang, but we have a couple of decades of psychology-<br>
of-programming results to show that it's a bad idea. I have<br>
started to replace by<br>
<br>
if X > Y -> a() if X > Y -> a()<br>
; true -> b() ; X =< Y -> b()<br>
end end<br>
<br>
if X > Y -> a() if X > Y -> a()<br>
; X < Y -> b() ; X < Y -> b()<br>
; true -> c() ; X ==Y -> c()<br>
end end<br>
<br>
which I find mildly annoying when _writing_ the code<br>
but enormously helpful when _reading_ it.<br>
<br>
This is one reason why I regard a proposal to add 'else'<br>
to Erlang as a bad idea.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Nice point. Really nice Erlangish way. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> An open question is if it should also be allowed to have expressions<br>
> without an 'else' clause, as proposed by Damien Katz, i.e.:<br>
><br>
> if Expression -> Body end<br>
<br>
</div>Obviously not, because<br>
<br>
if Guard -> Body end<br>
<br>
is already legal Erlang syntax.<br>
<div class="Ih2E3d"><br>
> Which might be useful in some cases, e.g.<br>
><br>
> if Logging -> log:write("Aiee") end,<br>
<br>
</div>Dijkstra's "A Discipline of Programming" gives arguments against<br>
using one-armed ifs in imperative code. In a mostly functional<br>
language it's even worse. Erlang gets this *right*: if you don't<br>
say what to do in some case, then a situation has arisen that<br>
your program does not handle, and the right answer is an exception.<br>
<div class="Ih2E3d"><br>
> In this particular case returning false might seem like a good idea,<br>
> but in other cases e.g. an empty list might be just as natural. I am<br>
> just not sure how to apply the rule of least surprise to this...<br>
<br>
</div>The rule of least surprise has a corollary:<br>
if there ISN'T a least surprising result,<br>
there is no result (that is, there is an exception).<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br><br>Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero!<br>Try Good Data now for free: <a href="http://www.gooddata.com">www.gooddata.com</a><br>