Replies: 1 comment 1 reply
-
I think the first thing encountered in If that is mistaken, may be someone can correct :) |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, I'm looking to use tree-sitter as the parsing frontend for my compiler.
Previous discussions have discouraged the use of tree sitter for this use case, but I think with a loose enough syntax description, the limited error information isn't an issue, which is far compensated for by tree-sitter's incredible parsing power, and ability to do local updates.
However, in using the parser, I need to convert tree-sitter's representation to my own. It would be very tedious and perhaps redundant to do sanity checking on every single tree node, so I want to know what guarantees tree sitter provides for its generated tree.
As an example, I've noticed that nodes with fixed size, with always either fully be ERROR, or fully have valid fields. Can I rely on this assumption?
Ex: The grammar
For the input:
Will generate the following:
Either the module is not a module but ERROR, or it is fully valid. But for example it wouldn't be a valid
module
node, with then an ERRORblock
field.Are there any concrete guarantees about this behaviour?
Another guarantee I'm interested in is if node types can occur that don't occur in the grammar. Like could the above
block
field actually contain anidentifier
?And finally maybe some trivia, but how does tree-sitter know which grammar element is the root node? I don't think
source_file
is a builtin, likeword
is?Beta Was this translation helpful? Give feedback.
All reactions