"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">But you'll happily imply that others should effect the change "</span><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;">Oh, no, I have given up on that. I can now see why it's not going to happen.</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;">"... </span></font>when _they_ tell you that they don't see the need for it, and give you _their_ reasons for not wanting to effect it -- you say hogwash! All on a change that's not that important to you!"</div>
<div><br></div><div>For some strange reason, it IS important to me when people misrepresent my positions. As you just did.</div><div><br></div><div>From the very first post I made on this thread, I talked about readability. You responded as if I had prioritized writeability over readability. Is that fair? Have you even *read* the first post I made on this? (Which pretty much laid out my entire case.) Or do you consider that a dispensable step in coming to a judgment of my position?</div>
<div><br></div><div>Here's the core paragraph from that first post:</div><div><br></div><div>"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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."</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">That's an argument in which readability weighs slightly more, isn't it?</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><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">-michael turner</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><br><div class="gmail_quote">On Sat, May 21, 2011 at 2:16 AM, Edmond Begumisa <span dir="ltr"><<a href="mailto:ebegumisa@hysteria-tech.com">ebegumisa@hysteria-tech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Fri, 20 May 2011 23:57:32 +1000, Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>> wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"... looking at both backward *and* forward compatibility issues (what sort<div class="im"><br>
of things might this change prevent us from doing in the future?)"<br>
<br>
I have repeatedly asked people here what this change would break, and in<br>
particular how it might compromise backward compatibility. Nobody has<br>
answered, so far. Since the change amounts to the compiler silently<br>
inserting a function name during parsing at points where some IDE<br>
environments already already insert the name literally when you type ";",<br>
it's pretty hard to see how there could be a backward compatibility issue.<br>
<br>
As for forward compatibility, we have it from Joe that syntax changes hardly<br>
every happen anyway. So if change is very unlikely to happen, forward<br>
compatiblity isn't much of an issue either, is it?<br>
<br>
As for how many meetings it would take Ericsson to establish that the risk<br>
is low/zero, well, OK, got me: I've worked as a software engineer in a<br>
couple of large companies, so I know that these things can take time. In<br>
fact, I remember life at one networking company where any single engineering<br>
change order to the production system required no fewer than 25 signatures.<br>
So you may have a point there. (Although I thought part of the point of open<br>
source was to circumvent that kind of bureaucratic tarpit. Guess I was<br>
wrong.)<br>
</div></blockquote>
<br>
One of the main motivations for a private company to open-source their proprietary code is to have *others* improve it not just have others make *suggestions* for its improvement. Suggestions can be obtained even with closed source software.<br>

<br>
Erlang has the EEP system for this. As others have suggested, if you really feel strongly on this prove everyone wrong! Write up an EEP. Show everyone that their fears are exaggerated. Supply a patch so we can see for ourselves how cool it would be! It wouldn't be the first time a skeptical community has been eventually convinced.<br>

<br>
But there's a problem with this...<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"Emacs for one would need work since it's syntax highlighting would now be<br>
broken."<br>
<br>
It would only be broken for any code that took advantage of the change I<br>
suggest. Which would start out at exactly zero percent of the Erlang code<br>
out there. As the supposed "harm" grew, well, somebody would go and modify<br>
whatever needed to be modified, to make syntax highlighting work as it does<br>
in Emacs already for the analogous syntax in Clojure.<br>
<br>
"If this is so important to you ...."<br>
<br>
It is not that important to me (at the moment.)<br>
</blockquote>
<br></div>
... it's not that important to you. You have better things to do correct? At the moment it's just a minor inconvenience, right? So why let it get to you?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, like anybody else,<br>
I hate having my case for change twisted by others, and I hate objections to<br>
ideas (mine and others) when the objections don't actually hold water.<br>
</blockquote>
<br></div>
So let me understand this...<br>
<br>
The change is not _that_ important to you (not important enough to effect it yourself.) But you'll happily imply that others should effect the change (which is fair enough BTW -- others may be far more intimate with the code that would need changing.) But when those others (those both more intimate with the code and whom you are essentially asking to make the change), when _they_ tell you that they don't see the need for it, and give you _their_ reasons for not wanting to effect it -- you say hogwash! All on a change that's not that important to you!<br>

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