re-introduce separators in concrete syntax

[chrisspre]

The current proposal as shown in http://rapid.rocks/docs/rsdl/rsdl-abnf is avoiding any form of separator. For example the list of properties of structured type is

"{" *( OWS structuredTypeMember ) OWS "}"

with a concrete snippet

{ id: Integer name: String displayName: String}

Any implementation of a parser and transformer will need to be able to show errors while parsing RSDL documents, especially in an early phase of design where the document changes rapidly. And it is essential to show multiple errors so that the user can make more rapid changes.

To show multiple errors in a document parsers typically rely on "recovery points". locations in the document where the parser can skip to so that it can restart parsing in a known state. Otherwise the parser would need to rely on long lookahead's and complicated "error case" syntax rules.

This proposal is to re-introduce

• commas (or semicolon) as separators in structuredType rule
• commas as separators in parameter lists (rule operation and serviceOperation)
• commas as separators in member lists of enum (rule enumType)
• commas as separators service elements (rule service)
• final semicolon after include statements (rule include)
• ...

[ralfhandl]

Additional:

• allow "separators" as "terminators" after the last element in a list, similar to JSON5 and JSONC
• make the "separator" / "terminator" optional if the "list" elements are separated by line-breaks, similar to statements in JavaScript

Which we would automatically get if we treat , as whitespace.

[chrisspre]

Additional:

• allow "separators" as "terminators" after the last element in a list, similar to JSON5 and JSONC
• make the "separator" / "terminator" optional if the "list" elements are separated by line-breaks, similar to statements in JavaScript

Which we would automatically get if we treat , as whitespace.

Adding a syntax rule for the first bullet point is relatively easy with just a optional separator terminal ... [','] . But the second bullet point requires quite dramatic changes to the current grammar: Treating comma as whitespace would probably be contextual but more importantly in todays grammar (not the ABNF but the implementation) whitespace can be completly ignored , not getting returned by the scanner/lexer/tokenizer) making whitespaces relevant in some cases would mean they have to be explicitly ignored in the grammar in other places. Something that is not necessary.

So in summary I am all for the first bullet point. But the second one makes the grammar unnecessarily complicated and harder to understand with very little benefit