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

[Anthony Ramine]

A parse transform input must be a well-formed Erlang AST.
You can't use that here. The parser will choke before it can parse
transform the AST.

Le 19 mai 2011 à 01:12, Steve Davis a écrit :

> Since this is the second thread on this issue, I'm assuming you feel
> very strongly about it. Why not file an EEP?
> 
> Also you have the option to write a parse transform if you hate it
> that much.
> 
> My view remains "if it ain't broke don't fix it", since after a few
> years of writing erlang programs, I do know that it ain't broke.
> 
> My respectful 2c.
> 
> /s
> 
> On May 18, 9:18 am, Michael Turner <michael.eugene.tur...@REDACTED>
> wrote:
>> Another objection raised against this syntax change is that all functional
>> languages violate DRY in this manner, so it's OK if Erlang does it too. This
>> is a Principle of Least Surprise argument, and not bad as far as it goes.
>> But how far does it go?
>> 
>> Erlang will have a better chance of greater success and survival if you
>> consider your recruitment base to be the overwhelming majority of
>> programmers. And from what I can tell,
>> 
>>  http://www.langpop.com
>> 
>> the overwhelming majority of programmers have no experience to speak of,
>> when it comes to functional programming languages. Appealing to the
>> "cross-training" benefit of coming from other FP languages seems like a
>> pretty weak argument. Especially since all I'm asking for here is syntactic
>> consistency *within* Erlang -- a PLoS argument in itself.
>> 
>> Richard O'Keefe suggests that the syntactic consistency goal is better met
>> by allowing a kind of limited-scope special-case fun name, permitting, e.g.
>> 
>>   Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.
>> 
>> I could get behind that too, but I don't follow his reasoning from syntactic
>> consistency, which is apparently that an unnamed fun has a name, it's just
>> the degenerate case of a name.  It's really there. We just can't see it. Hm,
>> really? If that were true in Erlang as it stands, shouldn't I be able to
>> write it this way?
>> 
>>   Fact = fun (0) -> 1; (N) -> N*''(N-1) end.
>> 
>> Looks like it's not quite that simple. It compiles, but it doesn't know what
>> module to look in for '', when it comes time to execute. In the shell, I get
>> an error indicating that it tried to resolve ''/1 as a shell command. Even
>> if I put it in a .erl file and compile it, there's no obvious way to tell
>> the compiler what module to look in. ?MODULE:'' doesn't work. Nor does
>> '':'', which I tried just for the hell of it.
>> 
>> What Richard's suggesting appears to require a rigorous re-think of how
>> scopes are defined in Erlang. What I'm suggesting amounts to simply asking
>> the compiler to do some of your tedious keying for you.
>> 
>> -michael turner
>> 
>> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> michael.eugene.tur...@REDACTED> wrote:
>>> I can say
>> 
>>>    fun (1)->2;
>>>         (2)->1
>>>    end
>> 
>>> but, oddly, I can't define a named function in the analogous way, e.g.:
>> 
>>>    factorial
>>>      (1) -> 1;
>>>      (N) -> N*factorial(N-1).
>> 
>>> gives me a syntax error. I find the latter more readable than
>> 
>>>    factorial(1) -> 1;
>>>    factorial(2) -> N*fact(N-1).
>> 
>>> It's also less to type and to read, which is consistent with the DRY
>>> principle ("Don't Repeat Yourself").  And it lends itself to reading a
>>> function definition as a set of cases. I think for Erlang newbies, it should
>>> therefore would be preferred: it helps underscore the pattern-matching style
>>> of Erlang function invocation.
>> 
>>> It also looks a *little* bit more like the mathematical convention for
>>> defining these sorts of functions, where you have "f(x) = ", centered
>>> vertically to the left of a big left "{" that (left-)encloses the list of
>>> expression/parameter-condition pairs in a two-column format, e.g.,
>> 
>>>  http://cnx.org/content/m29517/latest/Picture%2047.png
>> 
>>> So there's a (weak) argument from the Principle of Least Surprise here as
>>> well.
>> 
>>> It seems to me that, if anything, this requires only a *simplification* of
>>> the Erlang parser. That leaves only one obvious objection: would any
>>> existing code break if Erlang syntax were altered to allow this?
>> 
>>> -michael turner
>> 
>> 
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

--
Anthony Ramine
Dev:Extend
http://dev-extend.eu