Closed jgersti closed 2 years ago
Move the detection of Primitive
s into ParseCommandParameter(...)
This commit disallows the usage of tokenized primitves as selectors and function names.
The changed behaviour should only be noticeable if the predefined color names where used since hex colors, vectors and numbers should not be used as identifiers anyway.
Add IdentifierCommandParameter
This commit replaces all VariableCommandParameter
s which contain an AmbiguousStringVariable
where only the string value is used with an IdentifierCommandParameter
.
The first rule in branches for
AmbiguousSelector
is currently unnecessary.If an implicit (unquoted) string can never be an implicit (ambiguous) selector this rule will never used.
All implict AmbiguousStringCommandParameter
s have an empty token list and can therefore never be an AmbiguousSelector
(because no block type can be inferred).
Add AbsoluteCommandParameter
s to various rules and ...
This commit removes the rule that discards AbsoluteCommandParameter
. Any rule that needs to be aware of this has been changed to include an data processor that reads AbsoluteCommandParameter
.
This commit is more a quick fix and not proper solution since BlockCommandProcessor
now matches even more patterns (50+ million assuming only up to 2 assignment matches).
Multi-Word property support has some conflicts with this one, going in a different direction in order to support "To" separation.
closing this draft for now; we can revisit later.
This PR introduces the following changes:
to
(AbsoluteCommandParameter
) andin
(InCommandParameter
). All other tokens that are currently ignored can then be discarded before even invoking the actual parser. This allows removal of the rule that discardsIgnoreCommandParamter
andIgnoreCommandParameter
itself.VariableIncrementParameter
to include a optionalRelativeCommmandParameter
(by
). This allows removal of the rule that discardsRelativeCommandParameter
.IteratorComandParameter
to include a optionalInCommandParameter
. Modify the rules that producePropertySupplierCommandParameter
s to include a optionalInCommnadParameter
(in
) to the left in case of the rule forPropertyCommandParameter
and to the right in case of the rules forValuePropertyCommandParameter
. This handles all cases wherein
is used inside the test.AbsoluteCommandParameter
before theBlockCommandParameter
rule. This is a temporary measure to keep everything running for now . To resolve this theBlockCommandParameter
rule most likley needs to be split into seperate cases for assignment and increment/increase. All the assignment rules either before or after theBlockCommandParameter
need to be changed to consume aAbsoluteCommandParameter
~~ AddAbsoluteCommnadParameter
s to various rules and do not discard it as a standalone CP.Changes not yet included are:
Introduce aAdded. see belowIdentifierCommandParameter
to simplify/removeCanConvert
with checks likename.GetValue().value is AmbiguousStringVariable
.ParenethesisProcessor
,ListProcessor
andMultiListProcessor
with conventional rules. This might need some changes to the parser itself like a non consuming lookahead processor.BlockCommandProcessor
and the rules for item transfer (?) depend on this behaviour. As a first step add a paramter toRuleProcessor
that allows to select the desired behaviour and determine how many rules depend on the old behaviour.As a side note : I would propose to rename
*CommandParameter => *Token
,*DataProcessor => *Match
and the currentToken => Lexeme
. And maybe also renaming a few files to reflect what they containParameterParser.cs => Lexer.cs
,ProcessingEngine.cs => Parser.cs
_edit: