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

Should extras behavior be non-recursive? #3225

Open
yanok opened this issue Mar 27, 2024 · 1 comment
Open

Should extras behavior be non-recursive? #3225

yanok opened this issue Mar 27, 2024 · 1 comment
Labels
Milestone

Comments

@yanok
Copy link

yanok commented Mar 27, 2024

Problem

Right now extras is recursive: meaning that if there is a complicated (non-token) extra rule, other extras (including the rule itself!) could appear anywhere inside. While this is sometimes desirable, for example, one could get a nested /* */ comments just by adding an extra rule

comment: $ => seq('/*', repeat(/./), '*/')

but this could also be confusing:

  1. What if my language doesn't actually support nesting and this was not intended?
  2. Even if I want to support nested comments, I most likely don't want to show them as separate syntax nodes, just the top-level one, and there doesn't seem to be a way to achieve this.
  3. Worse than that, if I also have a single line comments //, defined as
    sl_comment: $ => seq('//', /[^\n]*/, '\n')
    as another extra rule, that can also appear inside comment, potentially breaking the /* balancing, such that
    /* /* // */
    */
    
    is invalid. Again, this might be what you want, but there is no control over it.

Expected behavior

I think the easiest thing is to just make extras non-recursive: rules listed in extras can appear anywhere expect for the rules listed in extras themselves. I guess there are not many extras usually, so there nesting is desired, it could be added explicitly.

Alternatively, there could be an additional configuration for extras, specifying for every pair of extra rules, if one could appear inside another, but that's probably an overkill.

@yanok yanok added the enhancement Feature request label Mar 27, 2024
@ObserverOfTime ObserverOfTime added this to the 0.23 milestone Apr 12, 2024
@ObserverOfTime
Copy link
Member

If you can implement this and it doesn't break, say comments with spaces inside, then feel free to submit a PR.

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

No branches or pull requests

2 participants