Thoughts on proposed comma changes?

[Richard Feldman]

I proposed a change to the way commas work in Elm, and it just occurred to me that I should probably post it on this list in case anyone wants to chime in. :)

[Adria Garriga]

I like it. I'm only worried it will introduce many errors when writing, but not having to deal with the commas at the beginning is comfy.

[Rehno Lindeque]

Yes please, massaging commas in templates, records, record updates is boring :)

[Gil Mizrahi]

Sorry, I'm against the proposal.

I think it does not contribute much to readability but is more error prone,  will probably have worst error messages when things go wrong and will consume too much time and effort to implement correctly, time and effort that can be spent doing more important tasks.

[Rehno Lindeque]

Sorry, I'm against the proposal.

I think it does not contribute much to readability but is more error prone,  will probably have worst error messages when things go wrong and will consume too much time and effort to implement correctly, time and effort that can be spent doing more important tasks.

Well in terms of effort, I'm of the opinion that people will still spin off some templating languages like jade if they perceive Elm's syntax to be noisy. I still feel at this point that I can write static jade quite a bit faster than static elm html. Not saying that this solves that entirely though (much of it is seems to have to do with the ease of writing classy divs in jade).

On being error prone, I guess you folk mean accidentally writing

[ fun

  arg

]

instead of 

[ fun

    arg

]

 

and that kind of thing?

It is occasionally a bit irritating in CoffeeScript, I'm not sure if I'll mind it with the assistance of the type-system...

[Corey Trampe]

I like this proposal a lot. The commas do feel rather cumbersome.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hassan Hayat]

I feel inclined to disagree with this proposal, although I must say that I don't have must experience with languages where commas are optional or non-existant. I've certainly played around with Clojure(script). Enough to make toy games and apps but not enough to claim with a straight face that I know Clojure. And, while I have heard the story about how people learn to love not having to write commas in Clojure and realize the uselessness of commas, I could never bring myself to omit them.

Furthermore, ever since the new exposing stuff was introduced, I've been increasingly inclined to be more verbose in the way I code. I've reduced the number of infix operators I use, I almost never expose functions, and I force myself to make my code look nice by rearranging code and indenting consistently etc even if it increases the code size. I know these things sound obvious but I feel like commas fit nicely with these things. Basically, the way I see it is I'm trading typing time for increased clarity. 

I think that having mandatory commas fits in nicely with the general philosophy in Elm of adding some verbosity and making things slightly more explicit in order to end up with code that is simpler, shorter, sweeter, way more maintainable and less error prone.

[Texas Toland]

I've been thinking about it too. I'm planning to reread your proposal tonight. My gut feel is it adds syntax (newlines interpreted as commas) without proportional increase in code comprehensibility or maintainability. @Richard Would you mind gisting one of the standard examples with it applied?

[Richard Feldman]

I feel inclined to disagree with this proposal, although I must say that I don't have must experience with languages where commas are optional or non-existant.

This seems to be an unfortunate trend in this discussion. Folks with substantial experience in both syntax styles seem to support the proposal, whereas those opposed seem to be generally inexperienced with comma-less, but concerned that it will be worse. Concern is natural and understandable, but I wish I could transplant my experience somehow...having spent a great deal of time using both systems, it's very clear which is the better UX!

 

I've reduced the number of infix operators I use, I almost never expose functions, and I force myself to make my code look nice by rearranging code and indenting consistently etc even if it increases the code size.

 

I think that having mandatory commas fits in nicely with the general philosophy in Elm of adding some verbosity and making things slightly more explicit in order to end up with code that is simpler, shorter, sweeter, way more maintainable and less error prone.

I agree with the first half but disagree with the conclusions. :)

I also have been using infix operators less, exposing functions less, rearranging code, indenting consistently, avoiding optimizing for vertical whitespace, etc. The thing is, with mandatory commas you end up with code that is objectively longer, and subjectively (from my perspective, and others in this discussion) less sweet, less maintainable, and more error prone.

If it were just a question of typing time, I wouldn't bother advocating so strongly for this. I'm motivated by all the time I've spent derailed by compiler errors that turned out to be a missing comma - which adds up to quite a lot when you're spending a lot of time doing the unglamorous (but very commonplace in app development) task of rearranging elements in elm-html view code. :)

[Richard Feldman]

Texas - great question! Here is TodoMVC with and without the proposal:

Current TodoMVC

TodoMVC with proposed comma changes

[Corey Trampe]

My goodness, yes.

--

[Kevin Peno]

I'd like it a lot more if those record definitions didn't need to be indented so much ;)

---

From: Corey Trampe
Sent: ‎7/‎7/‎2015 18:46
To: elm-d...@googlegroups.com
Subject: Re: [elm-discuss] Re: Thoughts on proposed comma changes?

[Kevin Peno]

Sorry, I know my last comment had nothing to do with the comma spec, which is certainly a step in the correct direction

---

From: Kevin Peno
Sent: ‎7/‎7/‎2015 18:52
To: elm-d...@googlegroups.com
Subject: RE: [elm-discuss] Re: Thoughts on proposed comma changes?

[Texas Toland]

Here is TodoMVC with and without the proposal:

Wow as Pete expected it really does clean up DSLs. Thanks Richard!

[Texas Toland]

if those record definitions didn't need to be indented so much

I think that's a consequence of not composing functions for elements in our demo. The syntax itself seems necessary.

[Max Goldstein]

I've thought about this and I honestly can't come to an opinion either way. I see the benefit of cleaner diffs, but I can also see those indented lists of lists breaking from their moores and getting mixed up. Also, error messages will take some time to get right, and you lose the ability to auto-format code (I much prefer Ruby to Python in that regard).

That said, it's good that we're pushing the boundaries of syntax. It means that we're less likely to have overlooked something, and made Elm the best it can be.

[dedo]

+1 ... mostly.

Is the line break at the end of line 161 or 165 (no-comma version) required by the proposal, or just a personal preference? Those lines with just an opening bracket on them do not improve readability for me, given that the items within are indented anyway. i.e.

          [ id "new-todo"
            placeholder "What needs to be done?"
            autofocus True
            value task
            name "newTodo"
            on "input" targetValue (Signal.send updates << UpdateField)
            onEnter (Signal.send updates Add)
          ]

reads better than

          [
            id "new-todo"
            placeholder "What needs to be done?"
            autofocus True
            value task
            name "newTodo"
            on "input" targetValue (Signal.send updates << UpdateField)
            onEnter (Signal.send updates Add)
          ]

[Kevin Peno]

I like the one you find less readable, but that should not be a language definition. My thinking its that whitespace alone should be enough (anything qualifying as regex \s)

---

From: dedo
Sent: ‎7/‎7/‎2015 21:13

To: elm-d...@googlegroups.com
Subject: Re: [elm-discuss] Re: Thoughts on proposed comma changes?

--

[Richard Feldman]

Yeah, that's just a personal preference because it's easier to rearrange things when every line starts with whitespace. The proposed syntax supports doing it either way.

[Joey Eremondi]

For readability, we should keep in mind that there's no commas between Let statements. They're purely whitespace delimited, and it's not hard to read.

On Tue, Jul 7, 2015 at 10:22 PM, Richard Feldman <richard....@gmail.com> wrote:

Yeah, that's just a personal preference because it's easier to rearrange things when every line starts with whitespace. The proposed syntax supports doing it either way.

--

[Richard Feldman]

That's a great point! I hadn't even considered that...

[Hassan Hayat]

Thanks for the example code. Hmm, I guess I'm just used to commas more because I prefer the version with commas. That said, I don't think it would be much for me to adapt. As I said, I only know languages with commas. Anyways, good luck with the proposal. If you think it really helps, then I can't wait for even more improvements. ;)

[Matt Ho]

I'm against this. Languages like clojurescript treat commas as optional which I think is great. At the same time, indentation in cljs doesn't matter. As I understand the proposal for elm, this would create some situations where indentation becomes important. I'm really concerned about this. Indentation should either always be important or not important at all. I'm worried about this middle case, where it's sometimes important.

One may argue it's just a small exception, but for a language that's already challenging to grok, adding more nuances to the wrong way to go.

M

[Matt Ho]

[Richard Feldman]

As I understand the proposal for elm, this would create some situations  where indentation becomes important.  I'm really concerned about this.  Indentation should either always be important or not important at all.  I'm worried about this middle case, where it's sometimes important.

Indentation already matters in Elm. If you try to compile this...

f =
    let foo = 1
    bar = 2
    in  
      foo

You get this compiler error:

indentation doesn't match

3|     bar = 2

       ^

I am looking for one of the following things:

    reserved word `in`

    whitespace

[Richard Feldman]

Perhaps more relevantly, indentation already matters in Elm and it hasn't been a problem. :)

[Max Goldstein]

Sure, but it's only mattered for control structures, not for data structures. Indenting control structures has been best practice since C, but data structures and function calls tend to be more fluid.