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

[Joe Armstrong]

On Wed, May 18, 2011 at 5:11 PM, Parnell Springmeyer <ixmatus@REDACTED>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You're being pedantic dude. I'm sure Joe Armstrong and the other
> programmers that designed and work on Erlang are acutely aware of DRY,
> PoLS, and a whole bunch of others.
>

Absolutly - DRY is tricky though - it's sometimes quicker
to repeat yourself than find the code to repeat. And sometimes
when you repeat yourself you find you didn't - you thought you
repeated yourself - bit on closer inspection you improved some
old version. Since I actually repeat myself a lot I have another
problem which of the 17 almost similar versions of X was the best ...

One the subject of syntax there's another inconstancy that nobody seems to
have noticed. All arguments in function calls *EXCEPT THE LAST* have commas
after them.

We write foo(a,b,c) but to make it easy to swap the arguments
we should write foo(a,b,c,) - actually C, Java and virtually every language
under the sun gets this wrong.

Oh and English clauses are separated by commas, *EXCEPT THE LAST*.

This, I think, would be a lot better,.

Or so it is argued on the placement of ;'s in Erlang :-)

Changing syntax is *incredibly difficult*  project managers get
apoplectic at the thought of retesting million lines of code - I know
they *should* be able to retest overnight - but sometimes they have
to book special purpose test facilities weeks in advance.

For those who want to experiment with a new syntax there is an
easy method - make a new file extension .erl1 hack the parser
and write some code that transforms .erl1 files to .erl.

If you want to think about language changes why don't we have a
long debate over higher order modules - not syntax.

Me, I'd like to say

   L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}]

   then have couple of new bifs Mod = list_to_mod(L) to compose
a module from a load of funs and mod_to_list to do the inverse.



/Joe






>
> Personally, I think it is a feature to state the function name when
> defining another function clause.
>
>    some_func(X, Y) ->
>        %% Long bit of code
>        ...;
>    some_func(X, []) ->
>        %% More code
>        ....
>
> Without it, scanning the source could get confusing.
>
> Michael Turner <michael.eugene.turner@REDACTED> writes:
>
> > 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-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> - --
> Parnell "ixmatus" Springmeyer (http://ixmat.us)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43
> Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo
> C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI
> MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx
> nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd
> 8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U=
> =ypYB
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20110518/a875ee79/attachment.htm>