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

[Frédéric Trottier-Hébert]

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