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

[Michael Turner]

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

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.

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.

-michael turner


On Sat, May 21, 2011 at 12:46 AM, Raimo Niskanen <
raimo+erlang-questions@REDACTED> wrote:

> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110521/1adc40aa/attachment.htm>