<br><br><div class="gmail_quote">On Thu, May 19, 2011 at 8:12 AM, Steve Davis <span dir="ltr"><<a href="mailto:steven.charles.davis@gmail.com">steven.charles.davis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since this is the second thread on this issue, I'm assuming you feel<br>
very strongly about it. Why not file an EEP?<br></blockquote><div><br></div><div>Pedantically: it's not an extension. Arguably, it's really just a bug, to be filed as "parser fails to parse function definitions consistently." If someone then tried to assert this inconsistency is an official inconsistency, because Erlang is *defined* this way, I'd ask, "where?" Where is the official document that sets forth what Erlang's syntax is? Is it that same document that describes the syntax of "let", a keyword reserved for use in some future that never seems to arrive?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Also you have the option to write a parse transform if you hate it<br>
that much.<br></blockquote><div><br></div><div>I don't hate it. I just don't see the point of the way things are now. And a parse transform would be enormous. A fix to the Erlang parser would probably be a few lines (leaving the parser shorter, no doubt).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My view remains "if it ain't broke don't fix it", since after a few<br>
years of writing erlang programs, I do know that it ain't broke.<br></blockquote><div><br></div><div>Brokenness is not the only fault a system can have. As far as I can tell, the worst consequence of the proposed change is that you'd start seeing code that looked like this:</div>
<div><br></div><div>fact</div><div> (0) -> 1;</div><div> (N) -> N*fact(N-1).</div><div><br></div><div>which is transparently obvious. So the argument that the change somehow makes code less readable makes no sense to me.</div>
<div><br></div><div>-michael turner</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
On May 18, 9:18 am, Michael Turner <<a href="mailto:michael.eugene.tur...@gmail.com">michael.eugene.tur...@gmail.com</a>><br>
wrote:<br>
<div><div></div><div class="h5">> Another objection raised against this syntax change is that all functional<br>
> languages violate DRY in this manner, so it's OK if Erlang does it too. This<br>
> is a Principle of Least Surprise argument, and not bad as far as it goes.<br>
> But how far does it go?<br>
><br>
> Erlang will have a better chance of greater success and survival if you<br>
> consider your recruitment base to be the overwhelming majority of<br>
> programmers. And from what I can tell,<br>
><br>
> <a href="http://www.langpop.com" target="_blank">http://www.langpop.com</a><br>
><br>
> the overwhelming majority of programmers have no experience to speak of,<br>
> when it comes to functional programming languages. Appealing to the<br>
> "cross-training" benefit of coming from other FP languages seems like a<br>
> pretty weak argument. Especially since all I'm asking for here is syntactic<br>
> consistency *within* Erlang -- a PLoS argument in itself.<br>
><br>
> Richard O'Keefe suggests that the syntactic consistency goal is better met<br>
> by allowing a kind of limited-scope special-case fun name, permitting, e.g.<br>
><br>
> Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.<br>
><br>
> I could get behind that too, but I don't follow his reasoning from syntactic<br>
> consistency, which is apparently that an unnamed fun has a name, it's just<br>
> the degenerate case of a name. It's really there. We just can't see it. Hm,<br>
> really? If that were true in Erlang as it stands, shouldn't I be able to<br>
> write it this way?<br>
><br>
> Fact = fun (0) -> 1; (N) -> N*''(N-1) end.<br>
><br>
> Looks like it's not quite that simple. It compiles, but it doesn't know what<br>
> module to look in for '', when it comes time to execute. In the shell, I get<br>
> an error indicating that it tried to resolve ''/1 as a shell command. Even<br>
> if I put it in a .erl file and compile it, there's no obvious way to tell<br>
> the compiler what module to look in. ?MODULE:'' doesn't work. Nor does<br>
> '':'', which I tried just for the hell of it.<br>
><br>
> What Richard's suggesting appears to require a rigorous re-think of how<br>
> scopes are defined in Erlang. What I'm suggesting amounts to simply asking<br>
> the compiler to do some of your tedious keying for you.<br>
><br>
> -michael turner<br>
><br>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div><div><div></div><div class="h5">> <a href="mailto:michael.eugene.tur...@gmail.com">michael.eugene.tur...@gmail.com</a>> wrote:<br>
> > I can say<br>
><br>
> > fun (1)->2;<br>
> > (2)->1<br>
> > end<br>
><br>
> > but, oddly, I can't define a named function in the analogous way, e.g.:<br>
><br>
> > factorial<br>
> > (1) -> 1;<br>
> > (N) -> N*factorial(N-1).<br>
><br>
> > gives me a syntax error. I find the latter more readable than<br>
><br>
> > factorial(1) -> 1;<br>
> > factorial(2) -> N*fact(N-1).<br>
><br>
> > It's also less to type and to read, which is consistent with the DRY<br>
> > principle ("Don't Repeat Yourself"). And it lends itself to reading a<br>
> > function definition as a set of cases. I think for Erlang newbies, it should<br>
> > therefore would be preferred: it helps underscore the pattern-matching style<br>
> > of Erlang function invocation.<br>
><br>
> > It also looks a *little* bit more like the mathematical convention for<br>
> > defining these sorts of functions, where you have "f(x) = ", centered<br>
> > vertically to the left of a big left "{" that (left-)encloses the list of<br>
> > expression/parameter-condition pairs in a two-column format, e.g.,<br>
><br>
> > <a href="http://cnx.org/content/m29517/latest/Picture%2047.png" target="_blank">http://cnx.org/content/m29517/latest/Picture%2047.png</a><br>
><br>
> > So there's a (weak) argument from the Principle of Least Surprise here as<br>
> > well.<br>
><br>
> > It seems to me that, if anything, this requires only a *simplification* of<br>
> > the Erlang parser. That leaves only one obvious objection: would any<br>
> > existing code break if Erlang syntax were altered to allow this?<br>
><br>
> > -michael turner<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> erlang-questi...@erlang.orghttp://<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">erlang.org/mailman/listinfo/erlang-questions</a><br>
<div><div></div><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>