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

[Steve Davis]

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