Closed stadelmanma closed 4 years ago
I'm actually on the fence about this again after thinking about it some more. Perhaps @maxbrunsfeld can weigh in on the "preferred conventions" for ASTs generated by tree-sitter in regards to end statements?
Hmm I’ve used Fortran 90 a long time ago, but I’m not really familiar with the problem you’re describing. Can you give some examples of things that you currently don’t parse correctly, and the change that you’re thinking of making?
Not a parsing problem just an AST generation question. It doesn't appear that any of the other grammars I have looked at have an "end_statement" rule that gets treated as a node.
Source code
PROGRAM TEST
bool_val = .TRUE.
bool_val = .FALSE.
END PROGRAM TEST
Current AST
(translation_unit
(program_block (identifier)
(assignment_statement (identifier) (boolean_literal))
(assignment_statement (identifier) (boolean_literal))))
vs
Proposed AST if I move forward with this issue
(translation_unit
(program_block (identifier)
(assignment_statement (identifier) (boolean_literal))
(assignment_statement (identifier) (boolean_literal))
(end_program_block (identifier))))
Ruby is one of the few languages I know of that uses actual "end" statements to close blocks and in that case the AST produced doesn't contain end statement tokens. However, that being said Ruby's end statements are simply 1 word. Fortran end statements vary in complexity.
Oh I see. My initial reaction is that I think it is worth having a node for it.
This is something I have been omitted so far since other languages don't have it but I think it would be useful here. Unlike Ruby's simple "end" used for all constructs Fortran end statements are specific to each construct and can contain labels and identifiers
This is moderately inconvenient since I'll have to fix a lot of test cases.