DRY principle and the syntax inconsistency in fun vs. vanilla functions

[Richard O'Keefe]

On 20/05/2011, at 11:20 AM, Frédéric Trottier-Hébert wrote:

> I don't agree with complaints either -- I have no issue with Erlang's syntax, lisp/scheme/racket's syntax or any other language. The reality, however, is that while programmers can pick up Erlang's syntax quickly, there's still an initial struggle to break what has been committed to muscle memory by many of the people I have taught it to.

Perhaps the biggest obstacle might be that = does not mean assignment,
or else that alphabetic case *does* matter but cannot be chosen freely.

Neither of which is something I'd change.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

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

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

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 <[hidden email]> 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 <[hidden email]>

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

"And why do you think I don't use Clojure?"

Uh, Richard, where did he say he thought that?

-michael turner

On Fri, May 20, 2011 at 5:40 PM, Richard O'Keefe <[hidden email]> wrote:

On 19/05/2011, at 5:03 AM, Jack Moffitt wrote:

>> I'm still waiting for the answer to the real showstopper question: would any
>> existing code break, under my proposal?
>
> Assuming the answer is no, then I think it's fine to fix the
> inconsistency an add this alternate notation.

No, it's not fine.

It fixes the WRONG END of the inconsistency.
It's like saying "Ooh, these people have two legs and those
people have one leg, the easiest thing to do is to cut one
leg off those who have too."

It harms readability in the eyes of a lot of people.

Like I said, you would have to pay me big money to read
code written in that style.

It certainly breaks *my* pretty-printer and editor.

Michael Turner is at perfect liberty to add any feature he
likes to his copy of Erlang.  He is at liberty to offer it
to other people.

> I'll also point out that this is name-less clause syntax is the same
> as in Clojure:
>
> (defn
>  mymax
>  ([x] x)
>  ([x y] (if (> x y) x y))
>  ([x y & more]
>   (reduce mymax (mymax x y) more)))

And why do you think I don't use Clojure?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

"... because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY
FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN."

And (he says, ears ringing slightly) that somehow makes it OK for any other part of the documentation to be wrong, even when your average learner is far more likely to encounter the erroneous passage first?

I eventually ran across the reference manual description.

Thanks for the update about the proportions of time spent scanning vs. parsing. I'm under the influence of something I heard Bill Joy (then a student of Sue Graham's) say about lex and yacc back around 1980 or so. In any case, can we at least agree that the change I suggest is going to have minimal impact on parsing times?

"If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable."

Even if it actually reduces the number of grammar rules, or keeps the number the same, and even if it means the same amount of head-match checking we have now?

"You are attacking one of the features of Erlang that I have found most helpful."

I found this "feature" helpful in a way myself: from doing some Prolog programming, I had some experience with writing code in this pattern. But when I was doing Prolog programming, I had the same complaint about Prolog: dreary repetition of redundant identifiers where whitespace and indentation would (I thought) enhance readability. It took some getting used to. But I suppose I could have learned to love it if I'd done more Prolog programming.

We have an eye of the beholder problem, here, obviously.

-michael turner

2011/5/20 Richard O'Keefe <[hidden email]>

On 20/05/2011, at 5:29 PM, Michael Turner wrote:
> "- 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.

That used to be true.  However, it's not clear that it _is_ true when the parser is
written in Yecc, as the Erlang parser is.  And it's not terribly important anyway,
because in the compilers I know anything about, the cost of scanning AND parsing
put together is less than half the total time.  (For example, one body of code that
I work with is parsed and semantic checked in under a second, but takes about 90
seconds for code generation.)

I just wrote a parser for someone else's scripting language last week.  Scanning
took less time than parsing, and the only reason code generation doesn't dominate
both is that it doesn't do any. 

>
> "- it doesn't make the parser code easier to maintain"
>
> It might, actually. See above.

If both the existing readable alternative and the proposed horrible one are
supported, the code *has* to increase in volume, and *has* to become less
maintainable.

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

Yes, because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY
FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN.

       1. You want to learn about syntax?
          Check the reference manual.
       2. You want to learn about something that goes
          in expressions?
          Check the expressions chapter.
       3. You want to learn about a particular kind of
          form?  Check the table of contents for that chapter.
       4. See 'fun expressions'?
          Click on it.

And there you are.

If you deliberately don't look in the reference manual, it's not
the fault of Erlang or its documenters.

There are plenty of things to improve, but before complaining about
the syntax, people really do have an obligation to look in the most
obvious place.

> "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 omitting the function name _anywhere_ in the first place is a weird and
pointless way to write code.

You are attacking one of the features of Erlang that I have found most
helpful.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Richter]

On 19 May 2011 18:47, Michael Turner <[hidden email]> wrote:

"It would, as others have pointed out, also be much harder to jump into a module and _know_ what the clause does since the function's name can be pages away."

 

It would only be harder ("much"??) if you *chose*, in such cases, to use the syntax I propose to bring over from multi-clause funs. In the case you bring up, it might be wiser not to. And what I propose clearly allows everyone to continue with the present syntax. So your argument for readability in this case comes down to "somebody might not use this language feature wisely." (*facepalm*).

Jumping into the party a bit late, but this caught my eye.

You do realize that sometimes people have to look at the code written by others, right?  Whether I choose to use this new syntax or not (and for the record I hate it), it will inevitably still impact me if others choose to use it.

 

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

Because (a) the generalisation I suggested was
       fun <optname> <args> <etc>
        {; <optname> <args> <etc>}...
       end
where <optname> is either a VARIABLE or omitted,
and is identical in each clause.
But '' is NOT a variable, now is it?

Thank you for the clarification. I see now that you had the fun "name" in upper case, in the code sample on the other thread. Perhaps that's enough for most people on this list to infer -- automatically and immediately -- that you really meant "variable" even when you were saying "name". But I've mostly been using regular programming languages for the last 30 years, which offer a little more freedom in variable naming, and I still fail sometimes to automatically think "variable" just because a non-macro identifier starts in upper case -- which is another old Prolog convention I always had trouble with. I apologize for being, um, you know ... merely average?

It's certainly a solution to a problem, I'd like to see it (or something like it) succeed, and I wish you luck with it.

-michael turner

On Fri, May 20, 2011 at 4:42 PM, Richard O'Keefe <[hidden email]> wrote:

On 19/05/2011, at 2:18 AM, Michael Turner 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.

I had a lengthy response to this which SquirrelMail (apparently that's the name of the
WebMail system here) managed to destroy.  Sigh.

Erlang has already survived very well for 30+ years with pretty much its present syntax.
It has also succeeded very well.

> And from what I can tell,
>
>   http://www.langpop.com
>
> the overwhelming majority of programmers have no experience to speak of,

Erlang's strengths come from being DIFFERENT.

There's a thing much discussed, much derided, and much practiced in Australia
and New Zealand, called "cultural cringe".  Look it up.  Cultural cringe hurt
ISO Prolog.  (Prolog _had_ a notation for integers in bases 2..36, but the
ISO committee threw it away and copied C instead, for base 16 only.  They
also changed the precedence of at least one operator to match C better than Prolog.)
If we go by fashion, we'll change Erlang to look like PHP or COBOL.
(Estimates of COBOL code volume range from 1e11 to 5e11 lines.)

Oh, I'd like all sorts of changes to Erlang syntax.  After Haskell, I find it
quite verbose.  I once designed a "Haskerl" syntax for Erlang that reduced the
line count by a factor of 1.6.  But syntax is not the most important thing about
Erlang (or LFE would not be of interest), and it's not really what needs the
most attention.  I think the Dialyzer is easily the most dramatic and important
thing that's happened to Erlang in some time, and if we want to talk about
improvements, that might have the highest payoff.

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

Because (a) the generalisation I suggested was
       fun <optname> <args> <etc>
        {; <optname> <args> <etc>}...
       end
where <optname> is either a VARIABLE or omitted,
and is identical in each clause.
But '' is NOT a variable, now is it?

And (b) the generalisation I suggested was to use
the SAME <optname> in each clause, and a completely
missing name is NOT the same as an empty but present
atom.  (This is like the way that in SQL92 a NULL
string is very different from an empty string.)

And note that I did not say that this is what Erlang *DOES*
do but what it might some day be *EXTENDED* to do as a way
of letting people write recursive funs.

By the way, some earlier posting from somebody said that
Erlang was alone in allowing multiple clauses in funs.
Not so.

Erlang Haskell ML
yes    yes     no     Are multiple arguments allowed in a lambda?
yes    no      yes    Are multiple clauses allowed in a lambda?

Erlang:
   fun ([_|_]) -> true
     ; ([])    -> false
   end

Standard ML:
   fn (_:_) -> true
    | []    -> false

While you *can* write

       val default = fn (SOME x) _ -> x
                      | NONE     d -> d

in SML, it is normal practice to write

       fun default (SOME x) _ = x
         | default NONE     d = d

and I think most SML programmers would regard the first alternative
as perversely unreadable.

>
>
> What Richard's suggesting appears to require a rigorous re-think of how scopes are defined in Erlang.

Not in the least.  The scope of a function name variable would be the function itself,
just like any other variable in the arguments of the clauses.

1> X = 1.
1
2> F = fun (X) -> ok ; (_) -> uh_oh end.
#Fun<erl_eval.6.13229925>
3> F(2).
ok

See how the X in the fun was *not* the X outside?
Same rule exactly for fun-names.

>  W

> hat I'm suggesting amounts to simply asking the compiler to do some of your tedious keying for you.
>
> -michael turner

(A) If repeating the function name is the most tedious keying you have,
   how fortunate you are!
(B) People with a decent text-editor don't have a problem anyway.
   One reason for putting case, if, fun, and receive semicolons at
   the beginning of the line is so that when you end a line with a
   semicolon, the editor can automatically
       - go back to the first preceding line to have a letter or '
         in column 1;
       - copy the function name into a work space
       - go back where it started
       - insert the work space.
   I did this years ago for Prolog.  I found it distracting, so
   switched the feature off, but anyone who really really hated
   retyping function names should be able to program this in a
   few minutes.
(C) The names are not there for the benefit of the compiler, but
   for the benefit of PEOPLE.  When you are reading someone else's
   code, it HELPS to see the function name in each clause.
   And that's why I'm willing to give head-room to fun-names.
   I really loathe seeing a bare argument list without any indication
   of what it's the argument list *of*.

>
>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <[hidden email]> 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).

I do not.  In fact I find the first version of factorial rather horrible.
If you really want to do that, you can write

   factorial(N) -> case N of
     (1) -> 1;
     (N) -> N*factorial(N-1) end.

right now.  Just don't ask me to read it for anything less than NZD 400/hour.

>
> It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself").

The DRY principle was not handed down on Mt Sinai.
It is a rule of thumb, no more and no less.
And indeed, it violates something I have found to be an excellent
guide, that a *controlled* use of redundancy is an aid to correctness.

For example, :- spec is redundant, but
- it lets Erlang detect a difference between what you DID write and
 what you MEANT to write
- someone can read the :- spec without having to read the code.

There are other examples of good redundancy in Erlang.

The keyword here, of course, is *controlled* redundancy; just enough to
do something useful (like helping human beings read your code, or
permitting some check), not too much.

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

That is one mathematical convention, followed in Miranda, and leading to
guards in Haskell and Erlang.  It is regrettable that SML does not have
them, but at least there's the 'nowhere' preprocessor to provide them.

There are other mathematical conventions.
"The Fibonacci numbers are defined using the linear recurrence relation
 

 with seed values:
 

 

" (Wikipedia entry on recurrence relations).

This is the style that Haskell, Clean, Mercury, SML, CAML, and so on follow.

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

Probably not.  However, the parser is a tiny part of the Erlang system, even a
tiny part of the compiler.  Simplicity of the parser per se is hardly worth
worrying about.  What matters is having a readable language.

Even if the change were made, every Erlang book and paper ever printed shows
the existing style.  How would newbies react to code that looked like nothing
they had ever been taught about?  What would happen to Erlang language-sensitive
editing tools, would they cope with the new syntax?  I know that the crude
pretty-printer I wrote for Erlang would have trouble, and the commands I now
find useful for moving to the next/previous clause would cease to work.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Edmond Begumisa]

> consider the needs of READERS in preference to WRITERS.

I found this statement nicely summed up the conflicting views on this  
thread. Very well put. And it puts the issue to rest IMO.

- Edmond -


On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe <[hidden email]>  
wrote:

>
> On 19/05/2011, at 4:08 AM, Michael Turner wrote:
>
>> "Sorry, but Erlang doesn't *need* a better chance of survival."
>>
>> Now, wait, I'm really pretty sure that, less than a year ago, I saw  
>> both Peyton-Jones and Armstong in a video, speculating about the future  
>> of their respective favorite languages, and openly wondering what the  
>> long-term future held.
>
> And?  Haskell is booming.  They tried to avoid success and failed  
> miserably.
>
>> In the meantime, I haven't noticed a dramatic increase in the frequency  
>> of Erlang job postings, though perhaps it's gone up. However, a  
>> doubling would still leave the number small.
>
> That does not mean that Erlang is under threat.  Come to think of it, R  
> is booming
> also.  There are at least 81 mirrors of CRAN to handle the download  
> volumes.  How
> many R jobs do you see?
>>
>> "Changing core language features that are solid,..."
>>
>> Except that that what I proposes fixes a weak spot (among other  
>> things): failed syntactic consistency.
>
> No, it leaves the *weak* spot (the absence of names in funs) along
> and smashes the *strong* spot.
>>
>> "... well thought out ..."
>>
>> Except that Joe Armstrong has just admitted (on this thread, IIRC) that  
>> the reason for the inconsistency is that they just didn't think about  
>> it at the time...."
>
> If you mean when "funs" were introduced, that may be so.
> But the repeated function names were copied from languages where it *WAS*
> well thought out, rather like you probably would not fault someone for
> designing a programming language using [] for array subscripting.
>
>>
>> "... and non-harmful ..."
>>
>> Implying that what I suggest here IS harmful?
>
> Yes, it is
> It would seriously impair readability.
> It would break several code processing tools that I use.
> It would drastically impair the usefulness of every existing Erlang book.
>>
>> Actually not. No amount of education and experience will make repeating  
>> the function name with every clause a DRY issue, for those who find  
>> that repetition as more of an obstacle than otherwise.
>
> Remember always to consider the needs of READERS in preference to  
> WRITERS.
>
> Take Haskell, as an example.  One of the advantages of Haskell is that  
> the
> types of functions can be inferred from their bodies (as long as you  
> stick
> to the standard language and don't use the rank 2 extension GHC offers).
> Why then do most Haskell programmers recommend writing down function  
> types
> anyway, even though that violates DRY?
>
> Because although the type *is* implicit in the code, and the *compiler*
> can figure it out, that doesn't mean it's easy for *humans*.
>
> If you are one of the people who find repeating function names an  
> obstacle
> (on present evidence, a set of cardinality one),
>  - you don't have to use Erlang
>  - you can always write cases if you want
>  - you could look into LFE
>  - you could write your own preprocessor
>
>
>> No amount of education and experience will keep people from wondering,  
>> "Why this strange inconsistency?"
>
> As a matter of fact, I've known about Erlang since about a year (maybe  
> two) since the first paper
> on it.  Since well before it *had* funs, in fact.  And you know, I've  
> *never* had that thought.
> I don't experience any inconsistency.
>
>> oAnd better documentation and training will only make more people ask  
>> that question. I didn't ask that question until I *stumbled* on the  
>> extended syntax for funs; I didn't know about it before.
>
> "Extended syntax for funs?"  What's that?  The syntax of funs is  
> described in
> chapter 7 of the reference manual, the chapter on expressions, which is  
> exactly
> where you would expect to find it.
>
> The inconsistency I see is that functions are OK but funs
> (a) do not permit a visible function name
>     -- just like Haskell, Clean, SML, CAML, &c
> (b) begin with "fun" instead of just beginning
>     -- just like Haskell, Clean, SML, &c
> (c) end with "end" instead of ending with a "."
>     -- the other languages I mentioned do not have any
>     -- terminator, so I usually find myself having to
>     -- wrap them in parentheses.  It's quite nice not
>     -- having to do that.
>
> However, (b) and (c) are unsurprising because funs are
> *expressions* and normal function definitions are not.
>
> If you are that upset about (a), I suggest that the inconsistency
> should be resolved by allowing funs to have names, as I've suggested,
> because that would fix the *other* difference between funs and
> normal functions, which is that normal functions can be directly
> recursive, and funs cannot.
>
> Your proposal to add a definition style that I find horrible for
> normal functions fails to do anything about that *other* difference
> between functions and funs.
>
> I repeat, you are urging that a *strong* spot be smashed to make
> it consistent with a *weak* spot, which is quite the wrong way around.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

Anyone who thinks that I address the needs of writers in preference to readers on this thread hasn't been reading me with much attention. Readability is somewhat in the eye of the beholder. A lot of the beholders on this list are seasoned Erlang programmers. It's pretty clear what they prefer: the way things are.

I happen to find the indented style I propose more readable. I have also said that I think programmers new to Erlang would tend to agree, although without a scientific test it would be hard to establish this, I admit. Some day, if Erlang survives, all the eyes on it will be new, because we'll all pass from the scene, eventually, one way or another. So it's not as if newbie opinion is utterly irrelevant here.

Disagreeing with my expressed position on readability is fair. Writing as if I'd never expressed that position, however, is not.

-michael turner

On Sat, May 21, 2011 at 12:04 AM, Edmond Begumisa <[hidden email]> wrote:

consider the needs of READERS in preference to WRITERS.

I found this statement nicely summed up the conflicting views on this thread. Very well put. And it puts the issue to rest IMO.

- Edmond -

On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe <[hidden email]> wrote:

On 19/05/2011, at 4:08 AM, Michael Turner wrote:

"Sorry, but Erlang doesn't *need* a better chance of survival."

Now, wait, I'm really pretty sure that, less than a year ago, I saw both Peyton-Jones and Armstong in a video, speculating about the future of their respective favorite languages, and openly wondering what the long-term future held.

And?  Haskell is booming.  They tried to avoid success and failed miserably.

In the meantime, I haven't noticed a dramatic increase in the frequency of Erlang job postings, though perhaps it's gone up. However, a doubling would still leave the number small.

That does not mean that Erlang is under threat.  Come to think of it, R is booming
also.  There are at least 81 mirrors of CRAN to handle the download volumes.  How
many R jobs do you see?

"Changing core language features that are solid,..."

Except that that what I proposes fixes a weak spot (among other things): failed syntactic consistency.

No, it leaves the *weak* spot (the absence of names in funs) along
and smashes the *strong* spot.

"... well thought out ..."

Except that Joe Armstrong has just admitted (on this thread, IIRC) that the reason for the inconsistency is that they just didn't think about it at the time...."

If you mean when "funs" were introduced, that may be so.
But the repeated function names were copied from languages where it *WAS*
well thought out, rather like you probably would not fault someone for
designing a programming language using [] for array subscripting.

"... and non-harmful ..."

Implying that what I suggest here IS harmful?

Yes, it is
It would seriously impair readability.
It would break several code processing tools that I use.
It would drastically impair the usefulness of every existing Erlang book.

Actually not. No amount of education and experience will make repeating the function name with every clause a DRY issue, for those who find that repetition as more of an obstacle than otherwise.

Remember always to consider the needs of READERS in preference to WRITERS.

Take Haskell, as an example.  One of the advantages of Haskell is that the
types of functions can be inferred from their bodies (as long as you stick
to the standard language and don't use the rank 2 extension GHC offers).
Why then do most Haskell programmers recommend writing down function types
anyway, even though that violates DRY?

Because although the type *is* implicit in the code, and the *compiler*
can figure it out, that doesn't mean it's easy for *humans*.

If you are one of the people who find repeating function names an obstacle
(on present evidence, a set of cardinality one),
 - you don't have to use Erlang
 - you can always write cases if you want
 - you could look into LFE
 - you could write your own preprocessor

No amount of education and experience will keep people from wondering, "Why this strange inconsistency?"

As a matter of fact, I've known about Erlang since about a year (maybe two) since the first paper
on it.  Since well before it *had* funs, in fact.  And you know, I've *never* had that thought.
I don't experience any inconsistency.

oAnd better documentation and training will only make more people ask that question. I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before.

"Extended syntax for funs?"  What's that?  The syntax of funs is described in
chapter 7 of the reference manual, the chapter on expressions, which is exactly
where you would expect to find it.

The inconsistency I see is that functions are OK but funs
(a) do not permit a visible function name
   -- just like Haskell, Clean, SML, CAML, &c
(b) begin with "fun" instead of just beginning
   -- just like Haskell, Clean, SML, &c
(c) end with "end" instead of ending with a "."
   -- the other languages I mentioned do not have any
   -- terminator, so I usually find myself having to
   -- wrap them in parentheses.  It's quite nice not
   -- having to do that.

However, (b) and (c) are unsurprising because funs are
*expressions* and normal function definitions are not.

If you are that upset about (a), I suggest that the inconsistency
should be resolved by allowing funs to have names, as I've suggested,
because that would fix the *other* difference between funs and
normal functions, which is that normal functions can be directly
recursive, and funs cannot.

Your proposal to add a definition style that I find horrible for
normal functions fails to do anything about that *other* difference
between functions and funs.

I repeat, you are urging that a *strong* spot be smashed to make
it consistent with a *weak* spot, which is quite the wrong way around.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--

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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Edmond Begumisa]

As I described previously: I actually think that the current syntax is  
*better for newbies* (especially those coming from imperative languages)  
since it drills-in Erlang's declarative nature. I view your proposal as  
something to cater for the experienced Erlanger who wants an alternative  
syntax for one-off scenarios.

- Edmond -

On Sat, 21 May 2011 01:19:43 +1000, Michael Turner  
<[hidden email]> wrote:

> Anyone who thinks that I address the needs of writers in preference to
> readers on this thread hasn't been reading me with much attention.
> Readability is somewhat in the eye of the beholder. A lot of the  
> beholders
> on this list are seasoned Erlang programmers. It's pretty clear what they
> prefer: the way things are.
>
> I happen to find the indented style I propose more readable. I have also
> said that I think programmers new to Erlang would tend to agree, although
> without a scientific test it would be hard to establish this, I admit.  
> Some
> day, if Erlang survives, all the eyes on it will be new, because we'll  
> all
> pass from the scene, eventually, one way or another. So it's not as if
> newbie opinion is utterly irrelevant here.
>
> Disagreeing with my expressed position on readability is fair. Writing  
> as if
> I'd never expressed that position, however, is not.
>
> -michael turner
>
> On Sat, May 21, 2011 at 12:04 AM, Edmond Begumisa <
> [hidden email]> wrote:
>
>> consider the needs of READERS in preference to WRITERS.
>>>
>>
>> I found this statement nicely summed up the conflicting views on this
>> thread. Very well put. And it puts the issue to rest IMO.
>>
>> - Edmond -
>>
>>
>>
>> On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe <[hidden email]>
>> wrote:
>>
>>
>>> On 19/05/2011, at 4:08 AM, Michael Turner wrote:
>>>
>>>  "Sorry, but Erlang doesn't *need* a better chance of survival."
>>>>
>>>> Now, wait, I'm really pretty sure that, less than a year ago, I saw  
>>>> both
>>>> Peyton-Jones and Armstong in a video, speculating about the future of  
>>>> their
>>>> respective favorite languages, and openly wondering what the long-term
>>>> future held.
>>>>
>>>
>>> And?  Haskell is booming.  They tried to avoid success and failed
>>> miserably.
>>>
>>>  In the meantime, I haven't noticed a dramatic increase in the  
>>> frequency
>>>> of Erlang job postings, though perhaps it's gone up. However, a  
>>>> doubling
>>>> would still leave the number small.
>>>>
>>>
>>> That does not mean that Erlang is under threat.  Come to think of it,  
>>> R is
>>> booming
>>> also.  There are at least 81 mirrors of CRAN to handle the download
>>> volumes.  How
>>> many R jobs do you see?
>>>
>>>>
>>>> "Changing core language features that are solid,..."
>>>>
>>>> Except that that what I proposes fixes a weak spot (among other  
>>>> things):
>>>> failed syntactic consistency.
>>>>
>>>
>>> No, it leaves the *weak* spot (the absence of names in funs) along
>>> and smashes the *strong* spot.
>>>
>>>>
>>>> "... well thought out ..."
>>>>
>>>> Except that Joe Armstrong has just admitted (on this thread, IIRC)  
>>>> that
>>>> the reason for the inconsistency is that they just didn't think about  
>>>> it at
>>>> the time...."
>>>>
>>>
>>> If you mean when "funs" were introduced, that may be so.
>>> But the repeated function names were copied from languages where it  
>>> *WAS*
>>> well thought out, rather like you probably would not fault someone for
>>> designing a programming language using [] for array subscripting.
>>>
>>>
>>>> "... and non-harmful ..."
>>>>
>>>> Implying that what I suggest here IS harmful?
>>>>
>>>
>>> Yes, it is
>>> It would seriously impair readability.
>>> It would break several code processing tools that I use.
>>> It would drastically impair the usefulness of every existing Erlang  
>>> book.
>>>
>>>>
>>>> Actually not. No amount of education and experience will make  
>>>> repeating
>>>> the function name with every clause a DRY issue, for those who find  
>>>> that
>>>> repetition as more of an obstacle than otherwise.
>>>>
>>>
>>> Remember always to consider the needs of READERS in preference to  
>>> WRITERS.
>>>
>>> Take Haskell, as an example.  One of the advantages of Haskell is that  
>>> the
>>> types of functions can be inferred from their bodies (as long as you  
>>> stick
>>> to the standard language and don't use the rank 2 extension GHC  
>>> offers).
>>> Why then do most Haskell programmers recommend writing down function  
>>> types
>>> anyway, even though that violates DRY?
>>>
>>> Because although the type *is* implicit in the code, and the *compiler*
>>> can figure it out, that doesn't mean it's easy for *humans*.
>>>
>>> If you are one of the people who find repeating function names an  
>>> obstacle
>>> (on present evidence, a set of cardinality one),
>>>  - you don't have to use Erlang
>>>  - you can always write cases if you want
>>>  - you could look into LFE
>>>  - you could write your own preprocessor
>>>
>>>
>>>  No amount of education and experience will keep people from wondering,
>>>> "Why this strange inconsistency?"
>>>>
>>>
>>> As a matter of fact, I've known about Erlang since about a year (maybe
>>> two) since the first paper
>>> on it.  Since well before it *had* funs, in fact.  And you know, I've
>>> *never* had that thought.
>>> I don't experience any inconsistency.
>>>
>>>  oAnd better documentation and training will only make more people ask
>>>> that question. I didn't ask that question until I *stumbled* on the  
>>>> extended
>>>> syntax for funs; I didn't know about it before.
>>>>
>>>
>>> "Extended syntax for funs?"  What's that?  The syntax of funs is  
>>> described
>>> in
>>> chapter 7 of the reference manual, the chapter on expressions, which is
>>> exactly
>>> where you would expect to find it.
>>>
>>> The inconsistency I see is that functions are OK but funs
>>> (a) do not permit a visible function name
>>>    -- just like Haskell, Clean, SML, CAML, &c
>>> (b) begin with "fun" instead of just beginning
>>>    -- just like Haskell, Clean, SML, &c
>>> (c) end with "end" instead of ending with a "."
>>>    -- the other languages I mentioned do not have any
>>>    -- terminator, so I usually find myself having to
>>>    -- wrap them in parentheses.  It's quite nice not
>>>    -- having to do that.
>>>
>>> However, (b) and (c) are unsurprising because funs are
>>> *expressions* and normal function definitions are not.
>>>
>>> If you are that upset about (a), I suggest that the inconsistency
>>> should be resolved by allowing funs to have names, as I've suggested,
>>> because that would fix the *other* difference between funs and
>>> normal functions, which is that normal functions can be directly
>>> recursive, and funs cannot.
>>>
>>> Your proposal to add a definition style that I find horrible for
>>> normal functions fails to do anything about that *other* difference
>>> between functions and funs.
>>>
>>> I repeat, you are urging that a *strong* spot be smashed to make
>>> it consistent with a *weak* spot, which is quite the wrong way around.
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> 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/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Joe Armstrong-2]

On Fri, May 20, 2011 at 12:44 AM, James Churchman <[hidden email]> wrote:

winner for the most nit-pickey thread ever 

also :

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

should be possible by generating a bit of ast and would indeed be a cool addition to the runtime :-)

Unfortunately not.

/Joe

   

 

On 19 May 2011 23:05, Edmond Begumisa <[hidden email]> wrote:

As I child I asked my mathematician father:

"Why is the number pad of a telephone in the flipped order from the number pad on a calculator/computer keyboard?"

His answer: "That's just the way it is."

Sometimes "that's just the way it is" is a perfectly sufficient and reasonable answer to both questions: why something is done a particular way; and why it shouldn't be changed.

Mind you on the noob argument: when I first started learning Erlang (my first functional language -- I had tried Lisp and gave up), I found the current syntax a very good learning aid. To use Turner's original example...

factorial(0) -> 1;
factorial(N) when N > 0 -> N*factorial(N-1).

I would read this as...

"The factorial of 0 is 1; the factorial of N when N is greater than zero is N times the factorial of N - 1."

Having the function name at the beginning of each clause helped me greatly to adapt to the declarative nature of Erlang. In contrast, I first struggled with multi-clause funs because my brain wanted so badly to use the anatomy of a function that I was so used to from imperative languages.

So I'd argue that changing this might make code actually *harder* for noobs when they come across it. The function names reinforce the declarative nature of Erlang, me thinks.

Besides, every programmer I know is a touch-typist -- it's not _that_ much work typing the function names :)

- Edmond -

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

On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford <[hidden email]> wrote:

Noting that I'm not against core language changes where critically
warranted, why is this one particular thing such an issue to you?

Erlang is not an ivory-tower-on-a-hill-university-project.  It's an
organically-grown beast that gets down in the trenches and brawls in the
mud.
If you don't like it, write it off as an "Erlang wart."  Every language has
them.  If you don't like it then write your own, or your own parser.

For what it's worth, some users (such as myself) actually PREFER it the way
it is because it makes code-scanning easier from a visual standpoint.
Yes, I'm one of those people who will put "comment breaks" between methods
in my code, too, regardless of language.

And to reference your copy-paste-mutate argument....what do you think we'll
be doing for every internal case-clause?  Yes, that's right,
copy-paste-mutate the pattern matches except that you now have your logical
branches at indent-level-1 with, potentially, the rest of your code that
doesn't deal with argument-specific code instead of at indent-level-0.  If
you need "common chunks of code" well, I'm pretty sure that's why we have
methods.  To wit, write your "unified interface"  and case it yourself and
call the argument specific sub-method.

My vote: keep it as it is.

<wipes-the-mud-off-his-beast-and-goes-back-to-work/>

-mox


On Wed, May 18, 2011 at 9:39 PM, Michael Turner <
[hidden email]> wrote:

Joe, with all due respect, I think you've misinterpreted DRY. It's not a
matter of writing something again because you can't find where it's already
implemented. In fact, the canonical example of DRY is to write something
that works for one case, and then, rather than define it as a function,
template or macro, and invoke it with varying parameters, instead
copy-paste-mutate for each case. In fact, the most common violations of DRY
are *precisely* when you know where the repeated code is, either because
you've just found it or because you've just written it.

"DRY says that every piece of system knowledge should have one
authoritative, unambiguous representation."

http://www.artima.com/intv/dry.html

Erlang function definition syntax has two representations in the parser --
for no good reason I can see. Why?

"Changing syntax is *incredibly difficult*  project managers get apoplectic
at the thought of retesting million lines of code -"

No existing code will use the syntax I suggest. So how can any of it break?

I have yet to get an answer: what could this proposed change possibly
break, even *theoretically*?

-michael turner

On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong <[hidden email]> wrote:

On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer <[hidden email]>wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, but Erlang doesn't *need* a better chance of survival. This
language is not just growing, it's booming. Changing core language
features that are solid, well thought out, and non-harmful (in other
words, they are, FEATURES) to make it more "adoptable" is a lot like
someone saying, "you have to quit that quirky smile so other people will
like you more."

Languages survive forever once they get to the point where

  1) legacy applications in the language still earn money
  2) it costs more to convert to a new language than maintain the
       existing app in the old language

Erlang reached this point, many years ago.

Right now Erlang companies have a commercial advantage
over non-erlang companies and so there is not much point in
trying to spread the language further - you just loose your commercial
advantage.

/Joe

Sometimes, yes, there are features in a language that could use
refinement - but many times, in a mature language, the ratio between
need and usefulness in refining a feature further, drops significantly.

Instead of changing something that is solid, educate the people that
have a hard time grasping it, build killer example applications that
exhibit the quirky style and idioms to a T - people /will/ follow it,
almost to a religious end.

That's actually what I like about Erlang the most, the documentation has
so many gems in it like the efficiency guide (where many common idioms
are expressed with clear DO and DON'T DO examples) and style guide.

RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more
consistent than many languages I've touched.

Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is
less consistent than Erlang's is in my opinion. The issue you are
attempting to get at is (again) an educational and experience one, not
something that is inherently wrong with the language or its expression
itself.

I'm actually baffled by the efforts people are putting into different
Erlang VM frontends that look like Ruby or Python. Good on them for
exercising the freedom of open source but /why/? Erlang's syntax is
almost beautiful to me now after using it, it's so well suited for what
Erlang is good at!

Erlang isn't that great for general purpose programming - you use
Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault
tolerance, easy parallelism (which isn't easy!), and hot code
loading. Features that are so difficult to do in the traditional
imperative environment that (to date) I have not seen a single
implementation of any one of those features that even approaches the
completeness of Erlang's.

Michael Turner <[hidden email]> writes:

> 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 <
> [hidden email]> 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
> [hidden email]
> 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+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX
8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN
aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S
QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf
i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw
h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc=
=GGPU
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Joe Armstrong-2]

On Fri, May 20, 2011 at 9:12 AM, Steve Strong <[hidden email]> 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.

You cannot imagine number of meetings involved - the time

to change the code base is tiny compared to the arguments

with project mangers etc...

 

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 <[hidden email]>

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Raimo Niskanen-2]

On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner 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

Like you ask, you get your answers.

It must be as simple as this: You ask the programmers here if this change
would break any old code. Most certainly it would not, as you claim.
But nobody will answer "this change is safe for all old code" because
firstly you did not ask that, and secondly everybody knows that the only
way to know for _sure_ is to implement the change and then see if it breaks
anything. And even then all you know is that you have not found any code
it breaks. Yet.

But allright, I'll say it! The change does not break any old code.
Happy now? But I might be wrong since I have not tested the change...

And that does not make the proposed change any better.

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

You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit.

For us one point of Open Source is to get bugfixes and beta testing.
We do not have to accept all suggested changes. Change without
thought can be bad for any project, Open Source or not.

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

You understate the impact. If our Emacs mode does not support all syntax
of the language, it is really broken. Also, the Vim users will be upset
until that is fixed. Add to this pretty printer, debugger, evaluator, ...
All should work for the would be current syntax. Leaving that to be fixed
later by the community is not an option.

>
> "If this is so important to you ...."
>
> It is not that important to me (at the moment.) 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.

I think that your claim that the change is small, simple and limited
does not hold water, when looking at the whole system.

>
> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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
> > [hidden email]
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >

> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions


--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Edmond Begumisa]

On Fri, 20 May 2011 23:57:32 +1000, Michael Turner  
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>
>> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[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 <[hidden email]> wrote:

On Fri, 20 May 2011 23:57:32 +1000, Michael Turner <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Michael Turner]

"You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit."

It's more like Joe's comment made me think that Erlang/OTP has to live in such a tarpit. I've lived in those as a programmer, it was hellish, so I can sympathize, if in fact that's anything like your situation. But it seems I misinterpreted him.

With that, I give up. Oh wait, also this: I really apologize if any of you chose to waste time on this thread. I'm sorry for making you do that. It's really all my fault.

-michael turner

On Sat, May 21, 2011 at 12:46 AM, Raimo Niskanen <[hidden email]> wrote:

On Fri, May 20, 2011 at 10:57:32PM +0900, Michael Turner 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

Like you ask, you get your answers.

It must be as simple as this: You ask the programmers here if this change
would break any old code. Most certainly it would not, as you claim.
But nobody will answer "this change is safe for all old code" because
firstly you did not ask that, and secondly everybody knows that the only
way to know for _sure_ is to implement the change and then see if it breaks
anything. And even then all you know is that you have not found any code
it breaks. Yet.

But allright, I'll say it! The change does not break any old code.
Happy now? But I might be wrong since I have not tested the change...

And that does not make the proposed change any better.

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

You indirectly say you think we (Erlang/OTP) are a bureaucratic tarpit.

For us one point of Open Source is to get bugfixes and beta testing.
We do not have to accept all suggested changes. Change without
thought can be bad for any project, Open Source or not.

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

You understate the impact. If our Emacs mode does not support all syntax
of the language, it is really broken. Also, the Vim users will be upset
until that is fixed. Add to this pretty printer, debugger, evaluator, ...
All should work for the would be current syntax. Leaving that to be fixed
later by the community is not an option.

>
> "If this is so important to you ...."
>
> It is not that important to me (at the moment.) 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.

I think that your claim that the change is small, simple and limited
does not hold water, when looking at the whole system.

>
> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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
> > [hidden email]
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >

> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________

erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[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  
<[hidden email]> 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 <
> [hidden email]> wrote:
>
>> On Fri, 20 May 2011 23:57:32 +1000, Michael Turner <
>> [hidden email]> 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 <[hidden email]>  
>>> 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 <[hidden email]>
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 21/05/2011, at 1:57 AM, Michael Turner 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.

That's principally because people find the proposed change so disgusting
that they don't greatly _care_ whether it is compatible or not;
it's not compatible with *them*.

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

If you mean "could there be existing code whose meaning would be altered by this
proposal", the answer is "no".
If you mean "could existing tools, including third-party tools, handle this",
the answer is "no, definitely not".
>
> "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.

The thing is that the number of people who took advantage of it is unknown and
and the amount of code that would be affected is unknown and how fast the change
would be adopted is unknown, so somebody using a well trusted tool would NEVER KNOW
WHETHER IT WAS GOING TO BREAK on some file maintained by someone else.

When the new syntax is in support of some new *semantics* that we have a
need for, such as the introduction of 'fun's in the first place, then that
is a price that can be worth paying.

When the new syntax is merely syntactic strychnine, no.

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

Then why are you wasting our time arguing for it?
I've written a working parser for someone else's language in less of my
time than you've wasted.

If you care about it, implement it yourself or pay someone else to.

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

I haven't noticed anyone twisting your idea or your case for.
You case is simply that it removes an "inconsistency" which
nobody else seems to perceive as an inconsistency (or if they
do, as one that needs fixing at the *other* end) and reduces
an already trivial amount of typing and makes the language
look more like other languages that many Erlang programmers
have gladly abandoned.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 21/05/2011, at 2:11 AM, Michael Turner wrote:

> "It seems to me that Michael Turner's argument is an argument from conservatism.
> Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl,
> all of these languages write a function name once and only once at the beginning
> of a function."
>
> But which of those allow more than one argument list?

It's not quite clear to me what you mean here, but

        add(x)to:(y)giving:(z)and:(w)

is perfectly good Algol 60.  Javascript allows things like f(1)(2).

And of course, anyone who knows Fortran knows that a Fortran subprogram
may have multiple entry points, and so multiple formal parameter lists.

If you mean "allow more than one CLAUSE", then the answer is that the languages
that allow more than one clause in a named function repeat the name, just like Erlang.

>  I think the indentation style I suggest also makes it more immediately obvious that Erlang features a kind of pattern-directed invocation.

People who are entirely new to Erlang are also entirely new to the idea of pattern directed
invocation, and if they aren't, they are also not new to the idea of repeating the function
name.  If you are new to pattern directed invocation, your indentation is not going to help
one iota:  one left parenthesis or square bracket looks much like another.

I will go this far: the discrepancy between functions and funs *is* a problem.
But it is the *funs* that are the problem, and the remedy is to let them have
names also.

Allowing names in funs is not a case of syntactic strychnine; not even a case
of syntactic sugar.  It actually provides new and desired semantics (directly
recursive funs), so it is at least _possible_ that it might repay the cost of
adopting it.  As things stand, I must say that I find multiclause funs in the
usual indentation style (that is, in the indentation style you are recommending
for normal functions) quite unreadable.

>
> As for what you claim is more readable, remember: the intuitive is the familiar. Someone who is entirely new to Erlang will perceive things differently.

The people who actually *teach* Erlang to people who have not met us before
tell us that they actually pick it up fairly easily.

> The only way to make the proposition "syntax X is more readable" a scientific one is to test -- on people *new* to Erlang.

Wrong.  What a tricky way to load the case in your favour!

The people who are entirely new to the language are the very LAST people you should
study; then you are measuring LEARNABILITY (or more FAMILIARITY), not READABILITY.

The kind of readability that matters is readability to people who have *some*
experience with the language.  People who have at least troubled to read an
Erlang book all the way through, and can be bothered to read the Erlang
reference manual once all the way through.  By the time you get that far,
you are not "entirely new" any more.

I can tell you this:  I went from knowing practically all the classic 60s and 70s
programming languages (including ones you've probably never heard of), including
Lisp, to learning Prolog.

And one thing that never EVER gave me the slightest trouble whatsoever was having
the name of a predicate repeated in each clause.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 21/05/2011, at 2:13 AM, Michael Turner wrote:

> "And why do you think I don't use Clojure?"
>
> Uh, Richard, where did he say he thought that?

He didn't, and I don't know why you think I think he thought that.

I was simply making the point that precisely because
"this is name-less clause syntax is the same as in Clojure"
it would be just as much a horrible mistake in Erlang as it
is in Clojure.

>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 21/05/2011, at 2:30 AM, Michael Turner wrote:

> "... because THAT IS COVERED IN THE REFERENCE MANUAL WHERE THE VERY
> FIRST THING AFTER THE SECTION HEADING SHOWS A MULTICLAUSE FUN."
>
> And (he says, ears ringing slightly) that somehow makes it OK for any other part of the documentation to be wrong,

I did not say that.
I did not say anything from which any reasonable person could infer that.
For one thing, I do not accept that the other part of the documentation
is WRONG, only that it is INCOMPLETE.
And yes, provided the reference manual is complete,
it IS ok for other documentation to be incomplete.

> even when your average learner is far more likely to encounter the erroneous passage first?

Only a very dumb and irresponsible learner would fail to check the reference manual.
Yes, you read the tutorials, you try the examples.
But when you want to know the details of something,
you read the reference manual.

IF you are competent at programming language learning.

> Thanks for the update about the proportions of time spent scanning vs. parsing. I'm under the influence of something I heard Bill Joy (then a student of Sue Graham's) say about lex and yacc back around 1980 or so. In any case, can we at least agree that the change I suggest is going to have minimal impact on parsing times?

Sure.  I don't actually _care_ about parsing times.
I care about the pain *I* would suffer if I had to read stuff written that way.
>
> "If both the existing readable alternative and the proposed horrible one are supported, the code *has* to increase in volume, and *has* to become less maintainable."
>
> Even if it actually reduces the number of grammar rules,

There is no reason to believe that it would do anything of the kind.

> or keeps the number the same,

There is no reason to believe that it would do anything of the kind.

> and even if it means the same amount of head-match checking we have now?

I don't know what you mean here.  I am not discussing run-time
complexity but the source code.
>
> "You are attacking one of the features of Erlang that I have found most helpful."
>
> I found this "feature" helpful in a way myself: from doing some Prolog programming, I had some experience with writing code in this pattern. But when I was doing Prolog programming, I had the same complaint about Prolog: dreary repetition of redundant identifiers where whitespace and indentation would (I thought) enhance readability. It took some getting used to. But I suppose I could have learned to love it if I'd done more Prolog programming.
>
> We have an eye of the beholder problem, here, obviously.

Compared with something like Haskell, Prolog can indeed be "drearily repetitive".
But the predicate names are NOT the dreary or noticeably repetitive part.

For what it's worth, the identifiers are *NOT* redundant in Prolog.
(Amongst other things, have you forgotten the existence of assertz/1?
 Or the :- discontiguous declaration?)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions