OysterKit is a framework that provides a native Swift scanning, lexical analysis, and parsing capabilities. In addition it provides a language that can be used to rapidly define the rules used by OysterKit called STLR
BSD 2-Clause "Simplified" License
177
stars
23
forks
source link
Lost identifier annotations in dynamic language generation #39
It's a bit of a mess really. There are two code paths one for LHR recursive rules and one for rules that aren't. In both cases if the expression for the grammar rule is just a single element that does generate a token the annotations are stripped from the new identifier (they either propagate into the expression or are lost).
I think the right solution is to make an identifier declaration rule different to others in that it is a rule with the token (the identifier) and the annotations on that declared identifier, but the MATCHER is taken from the expression's rule. You would have to be careful you don't end up with double tokens. If the token is transient then there isn't a problem.
GENERATED EXPRESSION'S RULE HAS A NON-TRANSIENT TOKEN OR ITS OWN ANNOTATIONS
WrappingRule(identifier, identifier annotations).matcher =
identifier(annotations).matcher = sequence(creating expression's token, annotated with the expression's annotations) of a single rule using the expressions matcher but stripped of its annotations and transient
GENERATED EXPRESSION'S RULE HAS A NON-TRANSIENT TOKEN
In the dynamic language extension of the
STLRIntermediateRepresentation.GrammarRule
It's a bit of a mess really. There are two code paths one for LHR recursive rules and one for rules that aren't. In both cases if the expression for the grammar rule is just a single element that does generate a token the annotations are stripped from the new identifier (they either propagate into the expression or are lost).
I think the right solution is to make an identifier declaration rule different to others in that it is a rule with the token (the identifier) and the annotations on that declared identifier, but the MATCHER is taken from the expression's rule. You would have to be careful you don't end up with double tokens. If the token is transient then there isn't a problem.
GENERATED EXPRESSION'S RULE HAS A NON-TRANSIENT TOKEN OR ITS OWN ANNOTATIONS
WrappingRule(identifier, identifier annotations).matcher = identifier(annotations).matcher = sequence(creating expression's token, annotated with the expression's annotations) of a single rule using the expressions matcher but stripped of its annotations and transient
GENERATED EXPRESSION'S RULE HAS A NON-TRANSIENT TOKEN
WrappingRule(identifier, identifier annotations).matcher = Expression's matcher