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

[Richard O'Keefe]

On 19/05/2011, at 4:08 AM, Michael Turner wrote:

> "Sorry, but Erlang doesn't *need* a better chance of survival."
> 
> Now, wait, I'm really pretty sure that, less than a year ago, I saw both Peyton-Jones and Armstong in a video, speculating about the future of their respective favorite languages, and openly wondering what the long-term future held.

And?  Haskell is booming.  They tried to avoid success and failed miserably.

> In the meantime, I haven't noticed a dramatic increase in the frequency of Erlang job postings, though perhaps it's gone up. However, a doubling would still leave the number small.

That does not mean that Erlang is under threat.  Come to think of it, R is booming
also.  There are at least 81 mirrors of CRAN to handle the download volumes.  How
many R jobs do you see?
> 
> "Changing core language features that are solid,..."
> 
> Except that that what I proposes fixes a weak spot (among other things): failed syntactic consistency.

No, it leaves the *weak* spot (the absence of names in funs) along
and smashes the *strong* spot.
> 
> "... well thought out ..."
> 
> Except that Joe Armstrong has just admitted (on this thread, IIRC) that the reason for the inconsistency is that they just didn't think about it at the time...."

If you mean when "funs" were introduced, that may be so.
But the repeated function names were copied from languages where it *WAS*
well thought out, rather like you probably would not fault someone for
designing a programming language using [] for array subscripting.

> 
> "... and non-harmful ..."
> 
> Implying that what I suggest here IS harmful?

Yes, it is
It would seriously impair readability.
It would break several code processing tools that I use.
It would drastically impair the usefulness of every existing Erlang book.
> 
> Actually not. No amount of education and experience will make repeating the function name with every clause a DRY issue, for those who find that repetition as more of an obstacle than otherwise.

Remember always to consider the needs of READERS in preference to WRITERS.

Take Haskell, as an example.  One of the advantages of Haskell is that the
types of functions can be inferred from their bodies (as long as you stick
to the standard language and don't use the rank 2 extension GHC offers).
Why then do most Haskell programmers recommend writing down function types
anyway, even though that violates DRY?

Because although the type *is* implicit in the code, and the *compiler*
can figure it out, that doesn't mean it's easy for *humans*.

If you are one of the people who find repeating function names an obstacle
(on present evidence, a set of cardinality one),
 - you don't have to use Erlang
 - you can always write cases if you want
 - you could look into LFE
 - you could write your own preprocessor


> No amount of education and experience will keep people from wondering, "Why this strange inconsistency?"

As a matter of fact, I've known about Erlang since about a year (maybe two) since the first paper
on it.  Since well before it *had* funs, in fact.  And you know, I've *never* had that thought.
I don't experience any inconsistency.

> oAnd better documentation and training will only make more people ask that question. I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before.

"Extended syntax for funs?"  What's that?  The syntax of funs is described in
chapter 7 of the reference manual, the chapter on expressions, which is exactly
where you would expect to find it.

The inconsistency I see is that functions are OK but funs
(a) do not permit a visible function name
    -- just like Haskell, Clean, SML, CAML, &c
(b) begin with "fun" instead of just beginning
    -- just like Haskell, Clean, SML, &c
(c) end with "end" instead of ending with a "."
    -- the other languages I mentioned do not have any
    -- terminator, so I usually find myself having to
    -- wrap them in parentheses.  It's quite nice not
    -- having to do that.

However, (b) and (c) are unsurprising because funs are
*expressions* and normal function definitions are not.

If you are that upset about (a), I suggest that the inconsistency
should be resolved by allowing funs to have names, as I've suggested,
because that would fix the *other* difference between funs and
normal functions, which is that normal functions can be directly
recursive, and funs cannot.

Your proposal to add a definition style that I find horrible for
normal functions fails to do anything about that *other* difference
between functions and funs.

I repeat, you are urging that a *strong* spot be smashed to make
it consistent with a *weak* spot, which is quite the wrong way around.