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

[Michael Turner]

On Thu, May 19, 2011 at 8:12 AM, Steve Davis <steven.charles.davis@REDACTED
> wrote:

> Since this is the second thread on this issue, I'm assuming you feel
> very strongly about it. Why not file an EEP?
>

Pedantically: it's not an extension. Arguably, it's really just a bug, to be
filed as "parser fails to parse function definitions consistently." If
someone then tried to assert this inconsistency is an official
inconsistency, because Erlang is *defined* this way, I'd ask, "where?" Where
is the official document that sets forth what Erlang's syntax is? Is it that
same document that describes the syntax of "let", a keyword reserved for use
in some future that never seems to arrive?


> Also you have the option to write a parse transform if you hate it
> that much.
>

I don't hate it. I just don't see the point of the way things are now. And a
parse transform would be enormous. A fix to the Erlang parser would probably
be a few lines (leaving the parser shorter, no doubt).


> 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.
>

Brokenness is not the only fault a system can have. As far as I can tell,
the worst consequence of the proposed change is that you'd start seeing code
that looked like this:

fact
  (0) -> 1;
  (N) -> N*fact(N-1).

which is transparently obvious. So the argument that the change somehow
makes code less readable makes no sense to me.

-michael turner


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110519/ec8f807f/attachment.htm>