It's just been pointed out to me (in a possibly *unintentionally* private e-mail) that this topic was already taken up on a recent thread:<div><br></div><div> <span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><a href="http://erlang.org/pipermail/erlang-questions/2011-May/058323.html" target="_blank" style="color: rgb(0, 0, 204); ">http://erlang.org/pipermail/erlang-questions/2011-May/058323.html</a></span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><a href="http://erlang.org/pipermail/erlang-questions/2011-May/058323.html" target="_blank" style="color: rgb(0, 0, 204); "></a><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I don't really understand one of the objections: that newbies would find it strange. When I started learning Erlang, even with some experience in lisp and prolog, I found *lots* of things strange.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">And yes, I understand that function clauses were borrowed from prolog. But an influence is not a stricture, especially when that influence is only partial, as it is here -- and maybe prolog wasn't doing it right either?</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">The better way to evaluate newbie-friendliness of the proposed syntactic change is to do it *scientifically*: teach some newbies both ways of writing function clauses, then see how well they do in timed code-comprehension tests where the only difference is the proposed change in syntax. I predict they'd actually have an easier time with what I propose, or at least do just as well.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">-michael<br>
</span></font><br><div class="gmail_quote">On Wed, May 18, 2011 at 6:16 PM, Michael Turner <span dir="ltr"><<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I can say<div><br></div><div> fun (1)->2;</div><div> (2)->1</div><div> end</div><div><br></div><div>but, oddly, I can't define a named function in the analogous way, e.g.:</div><div><br></div><div> factorial</div>
<div> (1) -> 1;</div><div> (N) -> N*factorial(N-1).</div><div><br></div><div>gives me a syntax error. I find the latter more readable than</div><div><br></div><div> factorial(1) -> 1;</div><div> factorial(2) -> N*fact(N-1).</div>
<div><br></div><div>It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself"). And it lends itself to reading a function definition as a set of cases. I think for Erlang newbies, it should therefore would be preferred: it helps underscore the pattern-matching style of Erlang function invocation.</div>
<div><br></div><div>It also looks a *little* bit more like the mathematical convention for defining these sorts of functions, where you have "f(x) = ", centered vertically to the left of a big left "{" that (left-)encloses the list of expression/parameter-condition pairs in a two-column format, e.g.,</div>
<div><br></div><div> <a href="http://cnx.org/content/m29517/latest/Picture%2047.png" target="_blank">http://cnx.org/content/m29517/latest/Picture%2047.png</a></div><div><br></div><div>So there's a (weak) argument from the Principle of Least Surprise here as well.</div>
<div><br></div><div>It seems to me that, if anything, this requires only a *simplification* of the Erlang parser. That leaves only one obvious objection: would any existing code break if Erlang syntax were altered to allow this?</div>
<div><br></div><font color="#888888"><div>-michael turner</div>
</font></blockquote></div><br></div>