<div>
<div>
<span>Do you seriously think that a compiler team of a well-established and widely used language would implement a new syntax in less than a day? The code change itself may be relatively trivial (or a total pain in the arse, I've not looked at the current compiler code and could believe either), but whichever it is, it will be dwarfed by the design meetings held prior to making the change - looking at both backward *and* forward compatibility issues (what sort of things might this change prevent us from doing in the future?), plus the testing that would need to be performed after.<br>
</span></div><div><span><br></span></div><div><span>And then there's all the tools that would be broken. Emacs for one would need work since it's syntax highlighting would now be broken. All this for a really minor change that, judging from the responses on this list, not that many people even want.</span></div><div><span><br></span></div><div><span>Dude, this thread has gone on long enough and wasted way too much time. If this is so important to you, then do it yourself (after all, it's less than a days work) and publish the changes.</span></div><div><span><br></span></div><div><span>Cheers,</span></div><div><span><br></span></div><div><span>Steve</span></div><div><span><br>-- <br>Steve Strong, Director, id3as<br><div>twitter.com/srstrong</div><br></span>
<!-- <p style="color: #a0a0a0;">On Friday, 20 May 2011 at 07:29, Michael Turner wrote:</p> -->
<p style="color: #a0a0a0;">On Friday, 20 May 2011 at 07:29, Michael Turner wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>Thank you, Frédéric, for taking a serious look at the idea. However, I see a few of the same unsubstantiated objections raised, with a couple more questionable ones added.<div><br></div><div>"- It makes it less obvious that a function has many clauses (see Steve Davis' code)"</div>
<div><br></div><div>WITH Steve's style of indentation. I suggested a more readable alternative, where the "(Args)->" part has indentation column to themselves. (Curiously, you employ my suggested indentation style yourself, below, in a supposedly "ambiguous" code sample.)</div>
<div><br></div><div>"- it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name."</div><div><br></div><div>Perhaps syntax would become even more regular than you suggest. What I propose results in a grammar more like this:</div>
<div><br></div><div> function:</div><div> clause-list + "."</div><div> fun:</div><div> "fun" + clause-list + "end"</div><div> clause:</div><div> [optional name] (arg-list) guards -> stmt-list</div>
<div><br></div><div>This is, if anything, more regular than the grammar is now. Yes, it *syntactically* allows for a *different* "optional name", but so does the current grammar; finding head mismatches *already* requires a separate step. And I question whether it requires the parser to produce a different AST than we get now, for parse-transform purposes.</div>
<div><br></div><div>The above syntax also permits naming in funs. Is that so bad? As ROK has suggested, pehaps funs ought to be allowed (limited-scope) names to facilitate recursive definition. I happen to think it would work just as well to re-use the keyword "fun" to refer to the fun in the process of being defined. But there's something to be said for self-documenting recursive funs, so I could go either way on that one. Or both ways. (I hear the moans: "Not *another* way to do the same thing..." -- as if they were actually the same. And as if I weren't proposing here to do things ONE way.)</div>
<div><br></div><div>"- it creates more learning overhead if both forms are used."</div><div><br></div><div>That depends on how you learn (and teach) a language. Really: how much more page space does it require to show a slightly different way to do something? And then there are different learner styles. After learning the basics of a language, I tend to flip to an appendix like "syntax summary" (in BNF and other semi-formal styles), to start exploring the meaning of different combinatorial possibilities -- it's often one of the most clarifying and delightful exercises I undertake. Alas, neither of the Erlang books has any such an appendix (mandatory for a programming language primer, I would have thought.) For me, that has made learning Erlang harder.</div>
<div><br></div><div>"- it's not faster (compile time, might even make compiling slower)"</div><div><br></div><div>You've got to be kidding. It's long been known: the time complexity of parsing is overwhelmingly dominated by scanning. Code written in the form I propose would have fewer tokens to scan.</div>
<div><br></div><div>"- it doesn't make the parser code easier to maintain"</div><div><br></div><div>It might, actually. See above.</div><div><br></div><div>"- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though."</div>
<div><br></div><div>Yes, it is. Not to mention that the documentation on Erlang syntax is due for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields the section "Syntax of funs", here:</div>
<div><br></div><div> <a href="http://www.erlang.org/doc/programming_examples/funs.html#id59209">http://www.erlang.org/doc/programming_examples/funs.html#id59209</a></div><div><br></div><div>Yes, believe it: no coverage of the multi-clause case.</div>
<div><br></div><div>"You'll be creating a hell of a lot more work ...."</div><div><br></div><div>Ah, it seems almost obligatory on this thread: exaggeration asserted as fact. Would it really require even as much as a day's work on the parser? Yes, it would require updating documentation of Erlang syntax, but that documentation that (see above) clearly needs a little work anyway.</div>
<div><br></div><div>"Oh and lastly, you could also have to consider this ambiguity ...."</div><div><br></div><div>It wouldn't even be an ambiguity. It would only be a weird and pointless way to write that code. And that's IF someone wrote code like that. Well, anybody can write crappy and confusing code that abuses any language feature. (There it is: my own obligatory exaggeration for this thread.) Any "obfuscated Erlang contest" would likely to whack the worst Obfuscated C out the ballpark. (And that's no exaggeration.)</div>
<div><br></div><div>-michael turner</div><br><div>2011/5/19 Frédéric Trottier-Hébert <span dir="ltr"><<a href="mailto:fred.hebert@erlang-solutions.com">fred.hebert@erlang-solutions.com</a>></span><br><blockquote type="cite"><div>Well let's take a look here. Syntax doesn't have to break old code to change, that's a good point.<br>
<br>
You'll see that if you try {lists, sort}([3,2,1]), you will obtain [1,2,3]. This basic fun syntax dates from before Erlang actually had funs (fun M:F/A). You'll notice that it was less complex, tends to avoid verbosity and is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going to the new syntax didn't break any code, didn't require old working code to be rewritten (things still work the old way, and parametrized modules are based on that bit of syntax) and people just ignore it if they don't need it. Yet people did the switch from {Mod, Fun} to fun M:F/A.<br>
<br>
Why? Because, I figure, people generally liked the new way better: it's faster (apparently much faster), much cleaner in intent and purposes, and way easier to figure out that we're actually dealing with a higher order function and not some weird concept. Plus you have to consider that in many places, you can just use 'Var(Args)' with either form. This switch had many wins over conciseness.<br>
<br>
If we try to do the same with your suggestion for the new Erlang syntax, we can basically see that it has a few advantages:<br>
<br>
- reduces typing required by avoiding name repetitions<br>
- it doesn't break existing code<br>
- it somewhat unifies the syntax with funs, but then funs still finish with 'end' and take no name.<br>
<br>
<br>
I, however, see the following disadvantages:<br>
<br>
- it creates multiple standards left to personal preference<br>
- it makes it less obvious that a function has many clauses (see Steve Davis' code)<br>
- it creates more learning overhead if both forms are used. {Mod,Fun} for funs has no overhead because it's basically deprecated and nobody uses it.<br>
- All the existing tools have to be updated to understand it -- at least those working on source files (and this includes editors and whatnot)<br>
<br>
To this, you must add a multiplier damage (heh) for things it doesn't make better:<br>
- it's not faster (compile time, might even make compiling slower)<br>
- it doesn't make the parser code easier to maintain<br>
- it doesn't make maintaining code in modules easier (except for some readability benefits)<br>
- it's not helping people understand the language better (based on my observations that people have no problems with the current form when it comes to understanding)<br>
- it's making a lot of documentation obsolete that will need to be updated. This is common to all changes though.<br>
<br>
In my opinion, typing less code, even if it doesn't break compatibility, is not worth the change. You'll be creating a hell of a lot more work if only to get a bit more concise and consistent syntax on a thing where people don't even agree you get better readability.<br>
<br>
<br>
Oh and lastly, you could also have to consider this ambiguity -- is the following bit of code acceptable?<br>
<br>
my_function<br>
(a,b,c) -> {a,b,c};<br>
(a,c,b) -> {a,b,v};<br>
my_function<br>
(c,b,a) -> {a,b,c}.<br>
<div><br>
<br>
On 2011-05-19, at 09:43 AM, Michael Turner wrote:<br>
<br>
> "Erlang is sufficiently mature that the syntax is now very difficult to change."<br>
><br>
> Nobody has yet told me why this proposed change would break any existing code, or why it would require any significant work on the parser.<br>
<br>
<br>
</div><div><div>--<br>
Fred Hébert<br>
<a href="http://www.erlang-solutions.com" target="_blank">http://www.erlang-solutions.com</a><br>
<br>
</div></div></div></blockquote></div><br>
</div><div>_______________________________________________<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">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div></div></span>
</blockquote>
<div>
<br>
</div>
</div>
</div>