[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions

[Raimo Niskanen]

On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner wrote:
> "... looking at both backward *and* forward compatibility issues (what sort
> of things might this change prevent us from doing in the future?)"
> 
> I have repeatedly asked people here what this change would break, and in
> particular how it might compromise backward compatibility. Nobody has
> answered, so far. Since the change amounts to the compiler silently

Like you ask, you get your answers.

It must be as simple as this: You ask the programmers here if this change
would break any old code. Most certainly it would not, as you claim.
But nobody will answer "this change is safe for all old code" because
firstly you did not ask that, and secondly everybody knows that the only
way to know for _sure_ is to implement the change and then see if it breaks
anything. And even then all you know is that you have not found any code
it breaks. Yet.

But allright, I'll say it! The change does not break any old code.
Happy now? But I might be wrong since I have not tested the change...

And that does not make the proposed change any better.

> inserting a function name during parsing at points where some IDE
> environments already already insert the name literally when you type ";",
> it's pretty hard to see how there could be a backward compatibility issue.
> 
> As for forward compatibility, we have it from Joe that syntax changes hardly
> every happen anyway. So if change is very unlikely to happen, forward
> compatiblity isn't much of an issue either, is it?
> 
> As for how many meetings it would take Ericsson to establish that the risk
> is low/zero, well, OK, got me: I've worked as a software engineer in a
> couple of large companies, so I know that these things can take time. In
> fact, I remember life at one networking company where any single engineering
> change order to the production system required no fewer than 25 signatures.
> So you may have a point there. (Although I thought part of the point of open
> source was to circumvent that kind of bureaucratic tarpit. Guess I was
> wrong.)

You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit.

For us one point of Open Source is to get bugfixes and beta testing.
We do not have to accept all suggested changes. Change without
thought can be bad for any project, Open Source or not.

> 
> "Emacs for one would need work since it's syntax highlighting would now be
> broken."
> 
> It would only be broken for any code that took advantage of the change I
> suggest. Which would start out at exactly zero percent of the Erlang code
> out there. As the supposed "harm" grew, well, somebody would go and modify
> whatever needed to be modified, to make syntax highlighting work as it does
> in Emacs already for the analogous syntax in Clojure.

You understate the impact. If our Emacs mode does not support all syntax
of the language, it is really broken. Also, the Vim users will be upset
until that is fixed. Add to this pretty printer, debugger, evaluator, ...
All should work for the would be current syntax. Leaving that to be fixed
later by the community is not an option.

> 
> "If this is so important to you ...."
> 
> It is not that important to me (at the moment.) However, like anybody else,
> I hate having my case for change twisted by others, and I hate objections to
> ideas (mine and others) when the objections don't actually hold water.

I think that your claim that the change is small, simple and limited
does not hold water, when looking at the whole system.

> 
> If you think the thread is a waste of *your* time, you're free to not
> contribute to it.
> 
> -michael turner
> 
> On Fri, May 20, 2011 at 4:12 PM, Steve Strong <steve@REDACTED> wrote:
> 
> >  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.
> >
> > 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.
> >
> > 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.
> >
> > Cheers,
> >
> > Steve
> >
> > --
> > Steve Strong, Director, id3as
> > twitter.com/srstrong
> >
> > On Friday, 20 May 2011 at 07:29, Michael Turner wrote:
> >
> > 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.
> >
> > "- It makes it less obvious that a function has many clauses (see Steve
> > Davis' code)"
> >
> > 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.)
> >
> > "- it somewhat unifies the syntax with funs, but then funs still finish
> > with 'end' and take no name."
> >
> > Perhaps syntax would become even more regular than you suggest. What I
> > propose results in a grammar more like this:
> >
> >  function:
> >    clause-list + "."
> >  fun:
> >   "fun" + clause-list + "end"
> >  clause:
> >    [optional name] (arg-list) guards -> stmt-list
> >
> > 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.
> >
> > 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.)
> >
> > "- it creates more learning overhead if both forms are used."
> >
> > 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.
> >
> > "- it's not faster (compile time, might even make compiling slower)"
> >
> > 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.
> >
> > "- it doesn't make the parser code easier to maintain"
> >
> > It might, actually. See above.
> >
> > "- it's making a lot of documentation obsolete that will need to be
> > updated. This is common to all changes though."
> >
> > 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:
> >
> >   http://www.erlang.org/doc/programming_examples/funs.html#id59209
> >
> > Yes, believe it: no coverage of the multi-clause case.
> >
> > "You'll be creating a hell of a lot more work ...."
> >
> > 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.
> >
> > "Oh and lastly, you could also have to consider this ambiguity ...."
> >
> > 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.)
> >
> > -michael turner
> >
> > 2011/5/19 Frédéric Trottier-Hébert <fred.hebert@REDACTED>
> >
> > Well let's take a look here. Syntax doesn't have to break old code to
> > change, that's a good point.
> >
> > 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.
> >
> > 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.
> >
> > 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:
> >
> > - reduces typing required by avoiding name repetitions
> > - it doesn't break existing code
> > - it somewhat unifies the syntax with funs, but then funs still finish with
> > 'end' and take no name.
> >
> >
> > I, however, see the following disadvantages:
> >
> > - it creates multiple standards left to personal preference
> > - it makes it less obvious that a function has many clauses (see Steve
> > Davis' code)
> > - 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.
> > - All the existing tools have to be updated to understand it -- at least
> > those working on source files (and this includes editors and whatnot)
> >
> > To this, you must add a multiplier damage (heh) for things it doesn't make
> > better:
> > - it's not faster (compile time, might even make compiling slower)
> > - it doesn't make the parser code easier to maintain
> > - it doesn't make maintaining code in modules easier (except for some
> > readability benefits)
> > - 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)
> > - it's making a lot of documentation obsolete that will need to be updated.
> > This is common to all changes though.
> >
> > 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.
> >
> >
> > Oh and lastly, you could also have to consider this ambiguity -- is the
> > following bit of code acceptable?
> >
> > my_function
> >   (a,b,c) ->  {a,b,c};
> >   (a,c,b) ->  {a,b,v};
> > my_function
> >   (c,b,a) -> {a,b,c}.
> >
> >
> > On 2011-05-19, at 09:43 AM, Michael Turner wrote:
> >
> > > "Erlang is sufficiently mature that the syntax is now very difficult to
> > change."
> > >
> > > 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.
> >
> >
> > --
> > Fred Hébert
> > http://www.erlang-solutions.com
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB