How to allow one-time matching of optional groups

[Yokozuna59]

Hi there, in yaml, it's only possible for each key to be declared one-time, so what is the best approach to matching different unordered rules that are optional?
So the following codes should be valid (ignoring other rules):

key1:

key2:

key1:
key2:

key2:
key1:

It would be possible to match unordered optional rules doing this, but not only one-time:

entry Model:
  (
    key1=KeyOne
    | key2=KeyTwo
  )*
  // other rules...
;

It's possible to match one-time by doing this, but it would be more complex if there were more possible rules:

interface Model {
  key1?: string;
  key2?: string;
}

entry Model returns Model:
  (
    key1=KeyOne
    & key2=KeyTwo
  ) | (
    key1=KeyOne
    | key2=KeyTwo
  ) | (
    {Model}
  )
  // other rules...
;

[msujew]

@Yokozuna59 This kind of semantic validation is out of scope for parsers. Parsers perform lexical analysis of text, while the semantic analysis should be performed on the parser result. That's what our validation engine/phase does in Langium.

I would recommend something like this instead:

entry Model:
  (keys+=(KeyOne | KeyTwo))*
  ...

Since you're parsing yaml, it might make sense to make the parser even more generic, with YamlEntry being just key: value.

entry Model:
  (items+=YamlEntry)*
  ...

Generally, parsers should be able to parse more than what is semantically valid. The advantage is mainly that you don't get cryptic parser errors but reasonable validation messages instead. It also reduces the risk of the parser just exiting the file completely, which results in incomplete AST results.

If you really want to go down that route, it should be enough to just write (key1=KeyOne & key2=KeyTwo & ...) though.

[Yokozuna59]

@msujew The main goal it to limit possible keys and values, e.g., wrap option should be only boolean:

wrap: true
wrap: false

I don't want to allow other values:

wrap: 'string'
wrap: "string"
wrap: >
  string
wrap: |
  string
wrap: string
wrap:
  - index
wrap:
  - key: value

[msujew]

I thought so, but the opinion I gave still holds up. While this sort of semantical analysis can be embedded in your parser, it's generally not a good idea to do so. Users will get pretty cryptic error messages in case they write something like wrap: "true", as generated parser errors are always worse than hand-crafted validation messages. Especially since parser errors result in error recovery, which might not result in a valid parse tree.

Again, when crafting a language/DSL it's important to differentiate between the lexical analysis and the semantic analysis. Validating specific yaml properties/values is 100% semantic analysis and should not be done by the parser.

If you really want to go down that route, it should be enough to just write (key1=KeyOne & key2=KeyTwo & ...) though.

[Yokozuna59]

You're right; strict possible values in the parser would be more complex and need more work to make it up-to-date with existing interfaces.
The current approach is already similar to this, allow any valid yaml code then process result.

But that for our use case, what should be the answer for the original answer?

[msujew]

In theory unordered groups (i.e. elements split via & should be used for this. However, our go-to approach is to just use normal repeated alternatives (i.e. (a | b | ...)* and validate that no duplicates appear. Everything else only results in cryptic parser error messages.