1. 24
  1. 7

    Did you just invent value-separated commas?

    1. 5

      The article’s suggested multiline string syntax is similar to what Zig has:

      const my_string =
          \\First line.
          \\Second line.

      This is really nice because you can align it properly with surrounding code. I hope other languages adopt this.

      1. 5

        Curious if this has any obvious advantages or deficiencies relative to nix’s indented strings, which I find pretty aesthetically pleasing.

        edit for illustration:

        let myString = ''
            leading indentation is stripped
            according to the first line
        1. 2

          C isn’t too far off either (no explicit concatenation – the preprocessor concatenates string literals):

          const char my_string[] =
              "First line.\n"
              "    Second line with internal indentation.\n"

          And I used to write printf statements like this:

          printf("a=%d b=%zu c=%02x"
              , a
              , b
              , c

          Sadly, there is no way any existing autoformatter is going to accept any of that. Maybe it’s fixable by writing yet another autoformatter, but I feel I always know better than the autoformatter, and never appreciated what it did to my code, so I wouldn’t have liked to contribute to such a problem.

        2. 3

          It appears to work a bit better for vertical formats than horizontal ones. But I do like the comma-first style—I may adapt that.

          1. 2

            An interesting write-up.

            For what it’s worth, I was writing quite a bit of LeetCode in OmniOutliner of all things, a few months back. I could basically write JavaScript in outline format, copy/paste into Sublime, and it’d be formatted pretty well. I’m still really keen on the idea of outlining code in OmniOutliner, and transforming it into real source (though mostly, I just stick to IntelliJ).

            2 things stood out:

            1. the closing } for a function would basically have to be nested inside it, so it can all collapse, otherwise you have 2 consecutive items “function foo(..) {” with all the code in it, plus a “}” to follow—this looks weird in code, but makes sense in the outline

            2. comments are nice when they’re in a separate column, even though I was still writing out “// …” instead of “…”

            1. 2

              Why do we need delimiters at all?

              numbers = [
              1. 3

                That has delimiters, they’re just contiguous runs of white space. [onetwothree] would be without delimiters, compare [one,two,three].

                1. 1

                  Most programmind languages use a model where whitespace is used to separate tokens and otherwise ignored, so f()g() is the same as f() g().

                  1. 2

                    I think you have to fully adopt a lisp like syntax to get away with not treating the white space differently in the context of the list. Say you skip the “white space as delimiter” in the case of [f()g()] you could argue there are no delimiters. [(one)(two)] seems like it should work as well. But is [x - y] equivalent to [x, -y] or [x-y]? And for my parens example is one(two) or one,two?

                    You can’t even always disambiguate with parens, if I mean x, -y and write [(x)(-y)] it can still be interpreted as x(-y). And if x (-y) means something different inside a list versus out the space is acting as a delimiter not just a token separator.

                    I’m using spaces for brevity but the same argument applies to new lines, imo. if




                    are different lists the new line is serving as a delimiter for the list, not just token separation.

                    1. 3

                      You don’t need to if your grammar has unambiguous ends. For example in a language I made you can have quite complex expressions with no parens. Of course it isn’t necessary a good idea, it can confuse readers if you don’t format the code well.

                      log-level = cond:[
                      	env == "dev" "warn"

                      I chose to keep the = between the keys and values for dictionaries but even that is mostly unnecessary (but it does allow a local a = 5 syntax without making local a keyword)


                      1. 2

                        Yeah, you can do it. IIUC ECL avoids the [x-y] problem because x-y is a single identifier, and x - y is an expression consistently. It avoids the one(two) problem by having the : for function application. So its lists really don’t have delimiters. I think you can also “solve” - by not reusing the same symbol for negation and subtraction.

                        1. 2

                          Yeah, operators that can be unary or binary is the enemy of this approach. I think right now ECL doesn’t have a negation operator. You need to do 0 - x. -1 is parsed as one token. But using a dedicated unary negation symbol would solve this.

                2. 1

                  this is what it would be like with no delimiters

                  numbers = onetwothree

                  but this is ambiguous

                3. 1

                  A delightfully through-the-looking-glass perspective. I should play with this idea more someday. <3

                  1. 1

                    It’s really great, and it’s probably better than trailing-comma separated values, but I will literally never write code with a leading comma. It looks stupid, and I can’t get over how much I hate seeing it. Position-independent symbols (like the dot used in the article) I would find completely palatable, though.

                    1. 1

                      That’s an excellent idea