O’CAML has optional trailing commas (actually semicolons) in lists and optional leading semicolons (actually vertical bars) in “case” (actually “match”) and “fun” (actually “function”) expressions.
It’s nearly 30 years since I added an “open a new line suitably indented and insert a comma at the end of the preceding line but ahead of an end of line comment unless there is already a comma there” command to my own text editor. It wasn’t hard. Since then I have regarded the terminators-are-better-than-separators as a relic of the punched card era. Your editor can colourise? Mine can’t. (I consider that a feature.) Your editor can offer context-sensitive completion? Mine can’t. (It originally ran on PDP-11s.). Your editor makes the absence of trailing commas a problem for you? What kind of dumbkopf editor are you using?
This was mentioned on the peer thread in the Elixir Forums, thought I’d mention it here too: another benefit is ease in moving lines around/commenting out by-line items:
[
1,
2,
3,
].
Here, the line with 3 can be moved up (with copy-paste or editor shortcut) or, much more common in my experience, commented out without leading to syntax errors. I find this more compelling than the clean-diff and auto-split arguments in favor, though they are nice as well.
This is a frustration even in Elixir where trailing commas are supported where syntactically unambigious, because the formatter removes them when run. The benefit extends to pretty much any multi-line-expression language that does commenting out by-line.
Y’know, I’ve been programming since I was in high school, which was about 55 years ago.
It’s amazing how often this has NOT been a problem for me.
How very seldom I find myself rearranging the items in a list manually.
When I do have a “volatile” list, the chances are that it is generated by some program,
and I just re-run the program, which puts commas in all the right places.
Being able to run a portion of your edit buffer through a command is liberating.
I don’t know why, but I get the strong impression that people suffering with wanting
language changes to fix editing issues are using some kind of IDE that isn’t easy
to extend the way Emacs or Vim (or Alpha of fond memory) are/were.
“Reorder list” and “add list element” are things that should be taken care of by the
language mode of your editor.
Obviously allowing a trailing comma just makes it a tiny bit easier as I don’t have to remove, and re-add it each time.
Personally I feel that you should not need anything other than a simple text editor to have a relatively good developer experience - I still love TextMate for quick edits or small updates because it is still one of the best looking editors around imo, and I often use plain ol Vim as that’s what we use on our servers.
Having said that I have no preference either way on this topic, even though from an aesthetic point of view I prefer to omit trailing commas, but as per the situation above, there is a time when it can be handy.
Unfortunately there are some problems no automated formatter that can solve:
[
"foo",
"bar" % last line was moved here
"baz",
]
Personally, I have the problem “fairly” ofter messing around with large rebar.config files or sys.config files etc and it is a quite frustrating cycle to figure out where the missing comma is. The Erlang parser naturally can’t really point out where the missing comma is, just where the syntax doesn’t make sense further down (sometimes a lot further!).
Perhaps… I’m a VIM user mostly (or VIM mode in other editors) and I don’t thinks it is “easy” to add such a feature. Also, we should cater to the many, not just the few in my opinion.
In the case shown, the Erlang parser should be able to pinpoint the location of the missing comma quite easily. (I said should. I’m not able to test whether it does right now.). (One of the arguments for ALR(1) parsers is that they can stop immediately after the longest prefix of the input that is a prefix of some valid sequence.)
As for catering to the needs of the many rather than the few, that is precisely the point of language modes as found in (what used to be thought of as giant) editors like Emacs and Vim. There is a mode for language Foo. It knows about how to style/colour Foo. It knows enough about the syntax of quotation to do parenthesis balancing for Foo — one reason why I hate sigils and 57 flavours of string. It provides some level of automatic indentation support for Foo. And it offers extra commands for common tasks in Foo. It gets written and maintained by a small group of people who know the arcane art of editor extension enhancement, but is available to many many people.
As for me, I shall continue to use my own editor which is TINY in comparison to Vim. And I shall continue to add tiny features to it when needed rather than whine about the programming language.
I don’t think so, I chose this example specifically because it is valid both with and without missing comma so there is no way for the parser to know what the programmer intended. If all lines had trailing commas already there would be no ambiguity.
It’s one (questionable) thing to add string pasting to a language,
but allowing comments in the gaps is, well, I want to be polite.
“foo”
“bar”
might be debatable, but
“foo” % comment
“bar”
really ought to be an error. Once triple-quoted strings were added to the language,
the rationale for string pasting vanished in a puff of evil-smelling smoke, and instances
of string pasting should be reported with warnings of likely mistakes. Instances of string
pasting with anything other than white-space characters in between should always have been
reported as probable errors. (We don’t have comments within numbers, so why allow comments
within strings?)
Can we now propose a language change
(strong) retire string pasting entirely
(weak) forbid comments in string pasting gaps?