The Language World's Weirdest COMMA! Mechanic

All right, I went and wrote it:

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

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

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


Wow, I'm in love with COMMA! in parse expressions. :heartpulse:

1 Like

I had a similar thoughts way back. I had originally wanted to copy the 'implied block' model of CSS and Ruby, but am now more or less on the same page as your proposal here.

1 Like

This may be a stretch, but I wonder if there's an argument here for copying a MarkDown convention for an alternative way to express URLs: allowing <> as delimiters. It would only apply to URLs that contain :// so as to distinguish from tags with namespaces.

One thought I had was that the COMMA! might represent a pause instead of a barrier when it came to enfix. This could make it a precedence manipulator:

>> add 1 2 * 3
== 7

>> add 1 2, * 3
== 9  ; as if you'd written `(add 1 2) * 3`

The current thought is it acts more like you've written (add 1 2) (* 3).

We probably want such an operator, but I don't think comma is it. The barrier behavior seems more reasonable and uniform, and lets you throw commas into lists of generated expressions and know that you're keeping them separate. (well, modulo hard quoting)