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

Steve Davis <>
Thu May 19 01:12:49 CEST 2011


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 <>
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 <
>
>
>
>
>
>
>
> > 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.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list