"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; ">You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit.</span>"<br>
</span><br>It's more like Joe's comment made me think that Erlang/OTP has to live in such a tarpit. I've lived in those as a programmer, it was hellish, so I can sympathize, if in fact that's anything like your situation. But it seems I misinterpreted him.<div>
<br></div><div>With that, I give up. Oh wait, also this: I really apologize if any of you chose to waste time on this thread. I'm sorry for making you do that. It's really all my fault.</div><div><br></div><div>-michael turner</div>
<div><br></div><div><br><div class="gmail_quote">On Sat, May 21, 2011 at 12:46 AM, Raimo Niskanen <span dir="ltr"><<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner wrote:<br>
> "... looking at both backward *and* forward compatibility issues (what sort<br>
<div class="im">> 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>
<br>
</div>Like you ask, you get your answers.<br>
<br>
It must be as simple as this: You ask the programmers here if this change<br>
would break any old code. Most certainly it would not, as you claim.<br>
But nobody will answer "this change is safe for all old code" because<br>
firstly you did not ask that, and secondly everybody knows that the only<br>
way to know for _sure_ is to implement the change and then see if it breaks<br>
anything. And even then all you know is that you have not found any code<br>
it breaks. Yet.<br>
<br>
But allright, I'll say it! The change does not break any old code.<br>
Happy now? But I might be wrong since I have not tested the change...<br>
<br>
And that does not make the proposed change any better.<br>
<div class="im"><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>
<br>
</div>You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit.<br>
<br>
For us one point of Open Source is to get bugfixes and beta testing.<br>
We do not have to accept all suggested changes. Change without<br>
thought can be bad for any project, Open Source or not.<br>
<div class="im"><br>
><br>
> "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>
</div>You understate the impact. If our Emacs mode does not support all syntax<br>
of the language, it is really broken. Also, the Vim users will be upset<br>
until that is fixed. Add to this pretty printer, debugger, evaluator, ...<br>
All should work for the would be current syntax. Leaving that to be fixed<br>
later by the community is not an option.<br>
<div class="im"><br>
><br>
> "If this is so important to you ...."<br>
><br>
> It is not that important to me (at the moment.) 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>
<br>
</div>I think that your claim that the change is small, simple and limited<br>
does not hold water, when looking at the whole system.<br>
<div><div></div><div class="h5"><br>
><br>
> 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">steve@srstrong.com</a>> wrote:<br>
><br>
> >  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">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">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>
<br>
> _______________________________________________<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>
<br>
<br>
</div></div><div class="im">--<br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">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></div>