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

[Michael Turner]

"But you'll happily imply that others should effect the change "

Oh, no, I have given up on that. I can now see why it's not going to happen.

"... when _they_ tell you that they don't see the need for it, and give you
_their_ reasons for not wanting to effect it -- you say hogwash! All on a
change that's not that important to you!"

For some strange reason, it IS important to me when people misrepresent my
positions. As you just did.

>From the very first post I made on this thread, I talked about readability.
You responded as if I had prioritized writeability over readability. Is that
fair? Have you even *read* the first post I made on this? (Which pretty much
laid out my entire case.) Or do you consider that a dispensable step in
coming to a judgment of my position?

Here's the core paragraph from that first post:

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

That's an argument in which readability weighs slightly more, isn't it?

-michael turner


On Sat, May 21, 2011 at 2:16 AM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

> On Fri, 20 May 2011 23:57:32 +1000, Michael Turner <
> michael.eugene.turner@REDACTED> wrote:
>
>  "... looking at both backward *and* forward compatibility issues (what
>> sort
>>
>> of things might this change prevent us from doing in the future?)"
>>
>> I have repeatedly asked people here what this change would break, and in
>> particular how it might compromise backward compatibility. Nobody has
>> answered, so far. Since the change amounts to the compiler silently
>> inserting a function name during parsing at points where some IDE
>> environments already already insert the name literally when you type ";",
>> it's pretty hard to see how there could be a backward compatibility issue.
>>
>> As for forward compatibility, we have it from Joe that syntax changes
>> hardly
>> every happen anyway. So if change is very unlikely to happen, forward
>> compatiblity isn't much of an issue either, is it?
>>
>> As for how many meetings it would take Ericsson to establish that the risk
>> is low/zero, well, OK, got me: I've worked as a software engineer in a
>> couple of large companies, so I know that these things can take time. In
>> fact, I remember life at one networking company where any single
>> engineering
>> change order to the production system required no fewer than 25
>> signatures.
>> So you may have a point there. (Although I thought part of the point of
>> open
>> source was to circumvent that kind of bureaucratic tarpit. Guess I was
>> wrong.)
>>
>
> One of the main motivations for a private company to open-source their
> proprietary code is to have *others* improve it not just have others make
> *suggestions* for its improvement. Suggestions can be obtained even with
> closed source software.
>
> Erlang has the EEP system for this. As others have suggested, if you really
> feel strongly on this prove everyone wrong! Write up an EEP. Show everyone
> that their fears are exaggerated. Supply a patch so we can see for ourselves
> how cool it would be! It wouldn't be the first time a skeptical community
> has been eventually convinced.
>
> But there's a problem with this...
>
>
>  "Emacs for one would need work since it's syntax highlighting would now be
>> broken."
>>
>> It would only be broken for any code that took advantage of the change I
>> suggest. Which would start out at exactly zero percent of the Erlang code
>> out there. As the supposed "harm" grew, well, somebody would go and modify
>> whatever needed to be modified, to make syntax highlighting work as it
>> does
>> in Emacs already for the analogous syntax in Clojure.
>>
>> "If this is so important to you ...."
>>
>> It is not that important to me (at the moment.)
>>
>
> ... it's not that important to you. You have better things to do correct?
> At the moment it's just a minor inconvenience, right? So why let it get to
> you?
>
>
>  However, like anybody else,
>> I hate having my case for change twisted by others, and I hate objections
>> to
>> ideas (mine and others) when the objections don't actually hold water.
>>
>
> So let me understand this...
>
> The change is not _that_ important to you (not important enough to effect
> it yourself.) But you'll happily imply that others should effect the change
> (which is fair enough BTW -- others may be far more intimate with the code
> that would need changing.) But when those others (those both more intimate
> with the code and whom you are essentially asking to make the change), when
> _they_ tell you that they don't see the need for it, and give you _their_
> reasons for not wanting to effect it -- you say hogwash! All on a change
> that's not that important to you!
>
> That position is a little unfair don't you think?
>
> - Edmond -
>
>
>
>
>  If you think the thread is a waste of *your* time, you're free to not
>> contribute to it.
>>
>> -michael turner
>>
>> On Fri, May 20, 2011 at 4:12 PM, Steve Strong <steve@REDACTED> wrote:
>>
>>   Do you seriously think that a compiler team of a well-established and
>>> widely used language would implement a new syntax in less than a day? The
>>> code change itself may be relatively trivial (or a total pain in the
>>> arse,
>>> I've not looked at the current compiler code and could believe either),
>>> but
>>> whichever it is, it will be dwarfed by the design meetings held prior to
>>> making the change - looking at both backward *and* forward compatibility
>>> issues (what sort of things might this change prevent us from doing in
>>> the
>>> future?), plus the testing that would need to be performed after.
>>>
>>> And then there's all the tools that would be broken.  Emacs for one would
>>> need work since it's syntax highlighting would now be broken.  All this
>>> for
>>> a really minor change that, judging from the responses on this list, not
>>> that many people even want.
>>>
>>> Dude, this thread has gone on long enough and wasted way too much time.
>>>  If
>>> this is so important to you, then do it yourself (after all, it's less
>>> than
>>> a days work) and publish the changes.
>>>
>>> Cheers,
>>>
>>> Steve
>>>
>>> --
>>> Steve Strong, Director, id3as
>>> twitter.com/srstrong
>>>
>>> On Friday, 20 May 2011 at 07:29, Michael Turner wrote:
>>>
>>> Thank you, Frédéric, for taking a serious look at the idea. However, I
>>> see
>>> a few of the same unsubstantiated objections raised, with a couple more
>>> questionable ones added.
>>>
>>> "- It makes it less obvious that a function has many clauses (see Steve
>>> Davis' code)"
>>>
>>> WITH Steve's style of indentation. I suggested a more readable
>>> alternative,
>>> where the "(Args)->" part has indentation column to themselves.
>>> (Curiously,
>>> you employ my suggested indentation style yourself, below, in a
>>> supposedly
>>> "ambiguous" code sample.)
>>>
>>> "- it somewhat unifies the syntax with funs, but then funs still finish
>>> with 'end' and take no name."
>>>
>>> Perhaps syntax would become even more regular than you suggest. What I
>>> propose results in a grammar more like this:
>>>
>>>  function:
>>>   clause-list + "."
>>>  fun:
>>>  "fun" + clause-list + "end"
>>>  clause:
>>>   [optional name] (arg-list) guards -> stmt-list
>>>
>>> This is, if anything, more regular than the grammar is now. Yes, it
>>> *syntactically* allows for a *different* "optional name", but so does the
>>> current grammar; finding head mismatches *already* requires a separate
>>> step.
>>> And I question whether it requires the parser to produce a different AST
>>> than we get now, for parse-transform purposes.
>>>
>>> The above syntax also permits naming in funs. Is that so bad? As ROK has
>>> suggested, pehaps funs ought to be allowed (limited-scope) names to
>>> facilitate recursive definition. I happen to think it would work just as
>>> well to re-use the keyword "fun" to refer to the fun in the process of
>>> being
>>> defined. But there's something to be said for self-documenting recursive
>>> funs, so I could go either way on that one. Or both ways. (I hear the
>>> moans:
>>> "Not *another* way to do the same thing..." -- as if they were actually
>>> the
>>> same. And as if I weren't proposing here to do things ONE way.)
>>>
>>> "- it creates more learning overhead if both forms are used."
>>>
>>> That depends on how you learn (and teach) a language. Really: how much
>>> more
>>> page space does it require to show a slightly different way to do
>>> something?
>>> And then there are different learner styles. After learning the basics of
>>> a
>>> language, I tend to flip to an appendix like "syntax summary" (in BNF and
>>> other semi-formal styles), to start exploring the meaning of different
>>> combinatorial possibilities -- it's often one of the most clarifying and
>>> delightful exercises I undertake. Alas, neither of the Erlang books has
>>> any
>>> such an appendix (mandatory for a programming language primer, I would
>>> have
>>> thought.) For me, that has made learning Erlang harder.
>>>
>>> "- it's not faster (compile time, might even make compiling slower)"
>>>
>>> You've got to be kidding. It's long been known: the time complexity of
>>> parsing is overwhelmingly dominated by scanning. Code written in the form
>>> I
>>> propose would have fewer tokens to scan.
>>>
>>> "- it doesn't make the parser code easier to maintain"
>>>
>>> It might, actually. See above.
>>>
>>> "- it's making a lot of documentation obsolete that will need to be
>>> updated. This is common to all changes though."
>>>
>>> Yes, it is. Not to mention that the documentation on Erlang syntax is due
>>> for an upgrade anyway. The first hit I get on "Erlang" and "fun" yields
>>> the
>>> section "Syntax of funs", here:
>>>
>>>  http://www.erlang.org/doc/programming_examples/funs.html#id59209
>>>
>>> Yes, believe it: no coverage of the multi-clause case.
>>>
>>> "You'll be creating a hell of a lot more work ...."
>>>
>>> Ah, it seems almost obligatory on this thread: exaggeration asserted as
>>> fact. Would it really require even as much as a day's work on the parser?
>>> Yes, it would require updating documentation of Erlang syntax, but that
>>> documentation that (see above) clearly needs a little work anyway.
>>>
>>> "Oh and lastly, you could also have to consider this ambiguity ...."
>>>
>>> It wouldn't even be an ambiguity. It would only be a weird and pointless
>>> way to write that code. And that's IF someone wrote code like that. Well,
>>> anybody can write crappy and confusing code that abuses any language
>>> feature. (There it is: my own obligatory exaggeration for this thread.)
>>> Any
>>> "obfuscated Erlang contest" would likely to whack the worst Obfuscated C
>>> out
>>> the ballpark. (And that's no exaggeration.)
>>>
>>> -michael turner
>>>
>>> 2011/5/19 Frédéric Trottier-Hébert <fred.hebert@REDACTED>
>>>
>>> Well let's take a look here. Syntax doesn't have to break old code to
>>> change, that's a good point.
>>>
>>> You'll see that if you try {lists, sort}([3,2,1]), you will obtain
>>> [1,2,3].
>>> This basic fun syntax dates from before Erlang actually had funs (fun
>>> M:F/A). You'll notice that it was less complex, tends to avoid verbosity
>>> and
>>> is somewhat more readable than doing (fun lists:sort/1)([1,2,3]). Going
>>> to
>>> the new syntax didn't break any code, didn't require old working code to
>>> be
>>> rewritten (things still work the old way, and parametrized modules are
>>> based
>>> on that bit of syntax) and people just ignore it if they don't need it.
>>>  Yet
>>> people did the switch from {Mod, Fun} to fun M:F/A.
>>>
>>> Why? Because, I figure, people generally liked the new way better: it's
>>> faster (apparently much faster), much cleaner in intent and purposes, and
>>> way easier to figure out that we're actually dealing with a higher order
>>> function and not some weird concept. Plus you have to consider that in
>>> many
>>> places, you can just use 'Var(Args)' with either form. This switch had
>>> many
>>> wins over conciseness.
>>>
>>> If we try to do the same with your suggestion for the new Erlang syntax,
>>> we
>>> can basically see that it has a few advantages:
>>>
>>> - reduces typing required by avoiding name repetitions
>>> - it doesn't break existing code
>>> - it somewhat unifies the syntax with funs, but then funs still finish
>>> with
>>> 'end' and take no name.
>>>
>>>
>>> I, however, see the following disadvantages:
>>>
>>> - it creates multiple standards left to personal preference
>>> - it makes it less obvious that a function has many clauses (see Steve
>>> Davis' code)
>>> - it creates more learning overhead if both forms are used. {Mod,Fun} for
>>> funs has no overhead because it's basically deprecated and nobody uses
>>> it.
>>> - All the existing tools have to be updated to understand it -- at least
>>> those working on source files (and this includes editors and whatnot)
>>>
>>> To this, you must add a multiplier damage (heh) for things it doesn't
>>> make
>>> better:
>>> - it's not faster (compile time, might even make compiling slower)
>>> - it doesn't make the parser code easier to maintain
>>> - it doesn't make maintaining code in modules easier (except for some
>>> readability benefits)
>>> - it's not helping people understand the language better (based on my
>>> observations that people have no problems with the current form when it
>>> comes to understanding)
>>> - it's making a lot of documentation obsolete that will need to be
>>> updated.
>>> This is common to all changes though.
>>>
>>> In my opinion, typing less code, even if it doesn't break compatibility,
>>> is
>>> not worth the change. You'll be creating a hell of a lot more work if
>>> only
>>> to get a bit more concise and consistent syntax on a thing where people
>>> don't even agree you get better readability.
>>>
>>>
>>> Oh and lastly, you could also have to consider this ambiguity -- is the
>>> following bit of code acceptable?
>>>
>>> my_function
>>>  (a,b,c) ->  {a,b,c};
>>>  (a,c,b) ->  {a,b,v};
>>> my_function
>>>  (c,b,a) -> {a,b,c}.
>>>
>>>
>>> On 2011-05-19, at 09:43 AM, Michael Turner wrote:
>>>
>>> > "Erlang is sufficiently mature that the syntax is now very difficult to
>>> change."
>>> >
>>> > Nobody has yet told me why this proposed change would break any
>>> existing
>>> code, or why it would require any significant work on the parser.
>>>
>>>
>>> --
>>> Fred Hébert
>>> http://www.erlang-solutions.com
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110521/ae10805d/attachment.htm>