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

[Edmond Begumisa]

Not only did I read your original post I even quoted it. Explaining  
exactly why _I_ thought it was less readable for Erlang new-comers, hence  
the only advantage left being writeability. Or do *you* pick and chose  
what you read?

- Edmond -

On Sat, 21 May 2011 03:51:22 +1000, Michael Turner  
<michael.eugene.turner@REDACTED> wrote:

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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/