Another objection raised against this syntax change is that all functional languages violate DRY in this manner, so it's OK if Erlang does it too. This is a Principle of Least Surprise argument, and not bad as far as it goes. But how far does it go?<div>
<br></div><div>Erlang will have a better chance of greater success and survival if you consider your recruitment base to be the overwhelming majority of programmers. And from what I can tell,<div><div><br></div><div> <a href="http://www.langpop.com">http://www.langpop.com</a></div>
<div><br></div><div>the overwhelming majority of programmers have no experience to speak of, when it comes to functional programming languages. Appealing to the "cross-training" benefit of coming from other FP languages seems like a pretty weak argument. Especially since all I'm asking for here is syntactic consistency *within* Erlang -- a PLoS argument in itself.</div>
<div><br></div><div>Richard O'Keefe suggests that the syntactic consistency goal is better met by allowing a kind of limited-scope special-case fun name, permitting, e.g.</div><div><br></div><div> Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.</div>
<div><br></div><div>I could get behind that too, but I don't follow his reasoning from syntactic consistency, which is apparently that an unnamed fun has a name, it's just the degenerate case of a name. It's really there. We just can't see it. Hm, really? If that were true in Erlang as it stands, shouldn't I be able to write it this way?</div>
<div><br></div><div> Fact = fun (0) -> 1; (N) -> N*''(N-1) end.</div><div><br></div><div>Looks like it's not quite that simple. It compiles, but it doesn't know what module to look in for '', when it comes time to execute. In the shell, I get an error indicating that it tried to resolve ''/1 as a shell command. Even if I put it in a .erl file and compile it, there's no obvious way to tell the compiler what module to look in. ?MODULE:'' doesn't work. Nor does '':'', which I tried just for the hell of it.</div>
<div><br></div><div>What Richard's suggesting appears to require a rigorous re-think of how scopes are defined in Erlang. What I'm suggesting amounts to simply asking the compiler to do some of your tedious keying for you.</div>
<div><br></div><div>-michael turner</div><div> <br><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></div></div>