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

Fri May 20 17:45:28 CEST 2011

On Fri, May 20, 2011 at 9:12 AM, 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.
>

You cannot imagine number of meetings involved - the time
to change the code base is tiny compared to the arguments
with project mangers etc...

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/916b7d9f/attachment.htm>