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

[Michael Turner]

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