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

[Edmond Begumisa]

> consider the needs of READERS in preference to WRITERS.

I found this statement nicely summed up the conflicting views on this  
thread. Very well put. And it puts the issue to rest IMO.

- Edmond -


On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe <ok@REDACTED>  
wrote:

>
> 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.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/