Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parser cannot delineating groupname and typename #193

Closed
jrandolf-2 opened this issue Jul 2, 2023 · 0 comments · Fixed by #202
Closed

Parser cannot delineating groupname and typename #193

jrandolf-2 opened this issue Jul 2, 2023 · 0 comments · Fixed by #202
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@jrandolf-2
Copy link
Contributor

jrandolf-2 commented Jul 2, 2023

I am building a TypeScript interface generator from CDDL (https://github.com/jrandolf/cddlconv) and ran into an issue involving groupnames and typenames.

Problem

Consider the following schema:

apple = ( int );

apple is by definition a type, however the parser believes this is a group. This follows from the parser thinking that the int is a groupname rather than a typename which can only be known if

  • the parser understands primitive types or
  • the parser has pre-parsed for group names.

Solutions

Pre-parsing group names

This involves storing a set in the parser that keeps track of declared group names in group rules. Schemas will either be order-dependent or order-independent, depending on the implementation.

Pros (order-dependent)

  • Simple to implement.

Cons

  • Order-dependent schemas.

Pros (order-independent)

  • Order-independent schemas.

Cons

  • Requires parsing several times until the group name set stabilizes.
  • Slow.

Registered types (recommended)

This is the complement of the first solution. Rather than storing group names, we store a set of type names that will delineate groupname and typename. It's sufficient to store the initial primitive type names (e.g. int) since the parser can distinguish higher level types based on the grammar. Taking the above example, int would be stored as a typename, implying apple is also a type.

Pros

  • Simple to implement.
  • In practice, schemas remain semantic [1] even if they are order-independent in comparison to the first solution.

Cons

  • Requires order-dependent schemas (but in practice, may not matter; see above pros).
  • Requires users to register unknown types beforehand [2]

[1] E.g. SomeComplexType may be a group or type depending on when its constituents get declared, but the validation rules will likely remain the same.
[2] It can also be a pro as users can declare their own "primitives"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants