All right, I went and wrote it:
Though sounding a bit like a broken record at this point, please add tests as you can think of them.
Due to having to juggle about a million design decisions at once that have actual deep difficult ramifications, I kind of have to draw the line after I feel I've gotten past any obvious disproofs of an idea...so the tests only go so far in the initial commit. Unfortunately that's about as far as they tend to stay until bugs are found.
>> all [1 + 2, 3 + 4]
== 7
>> all [1 +, 2 3 + 4]
** Script Error: + is missing its value2 argument
>> all [(1 +) 2 3 + 4] ; error parity
** Script Error: + is missing its value2 argument
I also did a quick patch of the feature into PARSE (it is difficult with how parse is written to do a "good" job of this, pointing to a conceptual problem with how parse is written, so a rewrite would hopefully address that):
>> parse "aaabbb" [some "a", some "b"]
== "aaabbb"
>> parse "aaabbb" [some, "a" some "b"]
** Script Error: expression barrier hit while fulfilling argument
Beyond the expression barrier feature--which I have always believed to be important--having comma available in dialects is powerful.
Note that I left in support for 1,1 being a synonym for 1.0 based on the idea of space significance. This means you'll have less ability to copy/paste data from other contexts directly, like (1,2,3) ... but it's not clear how much gain there is from allowing that when so many other things won't work (especially in plan -4, where foo(a, b c) isn't loadable either).
At least for the moment, this breaks the idea of supporting commas in URL!s directly. While it might be possible to say that http://a,b is legal but http://a, is not, how such things are scanned needs to be redesigned so there's not so much sporadic code all over the place. I'm open to the idea...just not assuming it as a foregone conclusion.
I Actually Like It
Many years ago when expression barriers were first being cooked up, I had been mostly swayed by the "commas and periods are too hard to tell apart" idea...to say that the only purpose they should have in the language would be as synonyms.
If this idea is taken to extremes, we would also say that the number 1 and lowercase L and the uppercase i and the vertical bar all have to be the same, due to I1l|. being too hard to differentiate. (Though fonts and syntax highlighting choices can go a long way in that.)
Today my thinking is that you don't necessarily control this kind of thing from the language level. You give people choices, and they write their code as it feels good to them. If they've got a certain mix of data and don't like comma with it, they should use another arrangement. Put things in groups, or on newlines, or whatever.
I'll point out you have the option to put an entire expression in a group, or just the last thing and keep the comma. It's up to you. So taking the maybe-ugly combo of blank-tailed TUPLE! and comma, you could go with your taste:
1 + a., 2 + 3
1 + (a.), 2 + 3
(1 + a.) 2 + 3
(1 + a.) (2 + 3)
[
1 + a.
2 + 3
]
It's something people can ignore entirely if they want. Don't use it if you don't like it. But right now, I like it...and I plan to phase out BAR! as an expression barrier in the default. But the mechanics are such that we know you can build usermode barriers if you want that to behave the same.
