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

[Edmond Begumisa]

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/