Are commas necessary outside of single-line arrays?

[parasyte]

I was looking at the Gura schema sketch I have been planning to try for my app, and I noticed that the comma array separators don't seem to be necessary (from tokenization or syntactic point of view) in multiline arrays.

Arrays of primitives can simply use line breaks as the element separator. Arrays of objects can use two line breaks as the element separator. This latter suggestion is even mentioned in the spec to encourage improving legibility:

# It is valid but a little hard to read
singers: [
    name: "Andrea"
    surname: "Bocelli"
    gender: "Opera",
    name: "Jimi"
    surname: "Hendrix"
    gender: "Rock"
]

# Much better!
singers: [
    name: "Andrea"
    surname: "Bocelli"
    gender: "Opera",

    name: "Jimi"
    surname: "Hendrix"
    gender: "Rock"
]

The comma could be removed from the second array in the example above while preserving intent. It must be included in the first array to parse correctly.

Going back to primitives, It looks better (IMHO) without commas:

# A long list with a lot of commas
states: [
    'Alabama',
    'Alaska',
    'Arizona',
    'Arkansas',
    'California',
    'Colorado',
    'Connecticut',
    'Delaware',
    # etc.
]

# A long list where each line is implicitly an individual item
states: [
    'Alabama'
    'Alaska'
    'Arizona'
    'Arkansas'
    'California'
    'Colorado'
    'Connecticut'
    'Delaware'
    # etc.
]

Why would anyone want to remove commas?

Gura is already sensitive to whitespace. And as shown in the example with arrays of objects, more whitespace increases legibility. It seems like commas are only useful in single-line arrays, since line breaks perform the same function (e.g. for key-value pairs in objects). It seems to me that removing the need for commas in multiline arrays will make arrays and objects more syntactically similar to one another without introducing parser ambiguity in most cases.

Perhaps commas should be optional. When I need to write a long array of numbers, I tend to put multiple elements on each line to optimize vertical space. For instance:

bytes: [
    0xfe, 0x44, 0x12, 0xf4, 0x02, 0x7a, 0x86, 0x00,
    0x4e, 0x89, 0x00, 0x3d, 0x94, 0x24, 0x51, 0x73,
    # etc.
]

I would not like to force removal of the trailing comma, especially for cases like this example.

As another bit of feedback, When I initially read the spec, the need for these commas stuck out as "unique" compared to the rest of the spec. This example particularly was surprising:

tango_singers: [
    user1:
        name: "Carlos"
        surname: "Gardel"
        year_of_birth: 1890,

    user2:
        name: "Aníbal"
        surname: "Troilo"
        year_of_birth: 1914
]

Only one line has a comma here. It is hard to spot at a glance. Unlike the blank line which really stands out. For this reason I believe that multiple line breaks should be the preferred separator for arrays of objects, without the comma.

Thoughts?

[Genarito]

Hi @parasyte!

The main advantage Gura has over other configuration languages is that it only allows a single way of doing things (a single type of booleans, a single start/end mark of an array, a single way of defining an object, etc).
Putting different rules depending on whether the array can be expressed in a single line or in many makes the language not only more complex but also makes parsers less maintainable and slower as these changes introduce a lot of valid rules when defining an array (and breaking changes with Gura 1.0).
We prefer to keep the essence of the language as simple as possible, which makes Gura easier to learn, maintain and use. As for visual beauty, you can use the IDE tools to add the line breaks you prefer, or always add a trailing comma (or remove it in case you don't like them). There are a lot of beautifiers for JSON, YAML, and TOML (and we expect for Gura too, soon), even for programming languages like Rust where there is a recommended official format and Linter which makes the job 😄

[parasyte]

My follow up question then is should commas be required on object key-value pairs for consistency with arrays?

Having commas in one context but not in others seems to go against the “one way to do things” mantra.

[Genarito]

Commas are a delimiter of the elements within an array. The following example:

ar: [
    elem1: true
    elem2: false
]

Will generate the JSON equivalent of:

{
  "ar": [
    {
      "elem1": true,
      "elem2": false
    }
  ]
}

Whereas:

ar: [
    elem1: true,  # <-- Note this comma
    elem2: false
]

Would generate:

{
  "ar": [
    {
      "elem1": true
    },
    {
      "elem2": false
    }
  ]
}

That's why in the example of the singers we use commas to delimit, that way it is consistent with the separation of different objects with all data types, even if the indentation between both elements already indicates that they are different objects (it could be due to the user forgetting to indent, commas solve this problem by forcing the user to delimit all elements with commas).

You can play with the equivalences using our configuration language translator and try those examples you were not clear about

[facundoq]

That's a good question. I agree with the sentiment that newlines are a sort of space management and that visually they are much better than commas. How about allowing both single new lines or commas, but not both? What would that look like? Just to think about it: array : [ 1, 2, 3,] or array: [1 2 3] But not : array: [1, 2, 3,] It would make it difficult to change from one format to the other though. The following would break, considering every line a new object singers: [ name: "Andrea" surname: "Bocelli" gender: "Opera" name: "Jimi" surname: "Hendrix" gender: "Rock" ] Or perhaps the issue is allowing objects in arrays to be defined being prefixed by a key, such as: singers: [ ab: name: "Andrea" surname: "Bocelli" gender: "Opera" jh: name: "Jimi" surname: "Hendrix" gender: "Rock" ] But this would make such keys mandatory, and would make it very difficult to interop. I guess JSON's use of braces comes in handy here, but we'd like to avoid those.

…

On Fri, Jun 24, 2022 at 4:09 PM Jay Oster ***@***.***> wrote: My follow up question then is should commas be required on object key-value pairs for consistency with arrays? Having commas in one context but not in others seems to go against the “one way to do things” mantra. — Reply to this email directly, view it on GitHub <#19 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMA6B57P2JOGMTILIIDH4LVQYBYBANCNFSM5ZYFANDA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[facundoq]

I agree but I think that what Jay is pointing to is a valid issue; in JSON, you have braces (show in bold) that clearly delimit when an object starts and ends. While I'm certainly not advocating for braces, it is true that arrays composed of objects look a bit weird. { "ar": [ * {* "elem1": true, "elem2": false * }* ] }

…

On Fri, Jun 24, 2022 at 4:34 PM Genaro Camele ***@***.***> wrote: Commas are a delimiter of the elements within an array. The following example: ar: [ elem1: true elem2: false] Will generate the JSON equivalent of: { "ar": [ { "elem1": true, "elem2": false } ] } Whereas: ar: [ elem1: true, # <-- Note this comma elem2: false] Would generate: { "ar": [ { "elem1": true }, { "elem2": false } ] } That's why in the example of the singers we use commas to delimit, that way it is consistent with the separation of different objects with all data types, even if the indentation between both elements already indicates that they are different objects (it could be due to the user forgetting to indent, commas solve this problem by forcing the user to delimit all elements with commas). You can play with the equivalences using our configuration language translator <https://config-translator.netlify.app/> and try those examples you were not clear about — Reply to this email directly, view it on GitHub <#19 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMA6BYORLNPBIRBBY5S2EDVQYEVDANCNFSM5ZYFANDA> . You are receiving this because you commented.Message ID: ***@***.***>

[parasyte]

That is a good way to put it. JSON avoids the ambiguity between the commas separating array elements and commas separating object key-value pairs with the help of the outer brackets. In Gura, this is only done with indentation and line breaks (for object key-value pairs) and commas (for array elements). It's the inconsistency that I am concerned with, and yes it does look weird.

[Genarito]

I understand the inconvenience. It's true that forcing the user to add a line break would make the document prettier. But it would break the "one way of doing things" scheme, which is the main advantage of Gura over YAML or even TOML. To me, the focus should be on providing tools to the user that add that optional line break automatically, without changing the rules that commas delimit elements within an array (all IntelliJ IDEs, and VS Code have automatic formatting, even customizable, in case the user wants more than one line break when dealing with objects in arrays).
Because it is true that visually it is more comfortable to add rules, but then there start to be drawbacks in terms of parsing, documentation, learning curve, breaking changes with respect to previous versions, among others