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

Add _SELF for recursive rules #14

Open
1 of 4 tasks
xparq opened this issue Sep 5, 2023 · 0 comments
Open
1 of 4 tasks

Add _SELF for recursive rules #14

xparq opened this issue Sep 5, 2023 · 0 comments

Comments

@xparq
Copy link
Owner

xparq commented Sep 5, 2023

(Requires #5/2: parent/child tree, for searching...)

It's impossible to deduce implicitly, which exact enclosing rule (level) a standalone (nullary) _SELF should refer to.

So, there should be support in the grammar def. syntax to mark a rule for later reference.

  • Currently, there's _DEF/_USE (_NAME, _CALL, _GOTO (and/or: _DEF, _USE, ...) #15), but TBH, that feels more like a workaround than a solution.
  • Come up with a light syntax + OPCODE semantics to mark a rule anonymously, for referencing it thereafter implicitly (by _SELF).
    • _SELF could then just mean _USE , and then "just" a solution for a (nullary) position marker would be needed.
    • The problem with that is... actually the same horrible burden, though, as the direct address references of e.g. _CALL_DIRECT, GOTO_DIRECT with auto-link #16...

Also note that named references -- albeit inefficient (full syntax-tree search for every deref.! :-o ) -- allow named rule definitions after a referencing _USE, whereas the implicit marker + _SELF logic couldn't really do that.

xparq added a commit that referenced this issue Sep 6, 2023
Nested structures like { some = code; { block; {another} stuff} yay }
can be parsed now recursively.

+ Rule tree: name lookup for _USE (no generic find() yet)
+ #14: Recursion is implemented, but not via _SELF yet
+ #15 (_DEF/_USE)
+ #28: Parser::run() added
+ OPERATORS -> CONST_OPERATORS, preparing to taking it seriously
  (RULE.name is mutable though, for _DEF to still work on const rules,
  but that's a tmp. kludge!)
+ Fix #29: Crash in _DEF for missing len = 0
+ Better diagnostics (tests, debug messages etc.)
+ Comments, cosmetics
xparq added a commit that referenced this issue Sep 6, 2023
Nested structures like { some = code; { block; {another} stuff} yay }
can be parsed now with (almost) the ususal recursive grammar productions.

+ Rule tree: name lookup for _USE (no generic find() yet)
+ #14: Recursion is implemented, but not via _SELF yet
+ #15 (_DEF/_USE)
+ #28: Parser::run() added
+ OPERATORS -> CONST_OPERATORS, preparing to taking it seriously
  (RULE.name is mutable though, for _DEF to still work on const rules,
  but that's a tmp. kludge!)
+ Fix #29: Crash in _DEF for missing len = 0
+ Better diagnostics (tests, debug messages etc.)
+ Comments, cosmetics
xparq added a commit that referenced this issue Sep 6, 2023
Nested structures like { some = code; { block; {another} stuff} yay }
can be parsed now with (almost) the ususal recursive grammar productions.

+ Rule tree: name lookup for _USE (no generic find() yet)
+ #14: Recursion is implemented, but not via _SELF yet
+ #15 (_DEF/_USE)
+ #28: Parser::run() added
+ OPERATORS -> CONST_OPERATORS, preparing to taking it seriously
  (RULE.name is mutable though, for _DEF to still work on const rules,
  but that's a tmp. kludge!)
+ Fix #29: Crash in _DEF for missing len = 0
+ Better diagnostics (tests, debug messages etc.)
+ Comments, cosmetics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant