Rewrite rules have a few limitations currently. Sometimes you match something in a line but in order to generate valid kit code, you have to put stuff on a line before. Or you want to generate a variable but not overwrite it or generate redefine errors (var x more than once). Or you could want to add something to the beginning or end of the scope the rules are acting on. So I'm suggesting a few additions to the capabilities of rewrite rules that should allow for rules doing way more than they can now.
$ALL - Represents the entirety of the code in the scope the rules are used on.
$INPUT - Give your rules some input like this using rules myRules(someInput). It can be one or any number of arguments. This means you can rewrite code to call other functions and determine what they will take in as input in a semantically nicer way than declaring a variable the line before with a special name or putting them on the first line of the scope it acts on.
$BEFORE - Any line prefaced with $BEFORE is rewritten the before the line the matched code is on. This lets you define variables, call functions, or whatever else even if the code around the matched code would cause errors if you just rewrote them into where it was matched exactly. Whenever $ALL is used, code before doesn't need to be prefaced with $BEFORE and code after with $AFTER because rewriting them in place would either be the same or be undefined.
$AFTER - See above.
$INCR - Represents an integer that increments each time any rewrite rule is called. This allows you to define variables in your rewrite rules and not have any issues of the variable being overwritten or generating a compiler error from defining a variable with the same name twice.
$foo:CONTAINING($bar, $baz, $etc) - This matches anything that contains the symbols in parentheses. The symbols in it would need to be matched on their own somewhere else in the same rewrite rule otherwise it would give a compiler error.
Rewrite rules have a few limitations currently. Sometimes you match something in a line but in order to generate valid kit code, you have to put stuff on a line before. Or you want to generate a variable but not overwrite it or generate redefine errors (
var xmore than once). Or you could want to add something to the beginning or end of the scope the rules are acting on. So I'm suggesting a few additions to the capabilities of rewrite rules that should allow for rules doing way more than they can now.Here's a demo file so you can see it in your editor of choice or whatever: new_rewrite_rule_demo.kit.zip
$ALL- Represents the entirety of the code in the scope the rules are used on.$INPUT- Give your rules some input like thisusing rules myRules(someInput). It can be one or any number of arguments. This means you can rewrite code to call other functions and determine what they will take in as input in a semantically nicer way than declaring a variable the line before with a special name or putting them on the first line of the scope it acts on.$BEFORE- Any line prefaced with$BEFOREis rewritten the before the line the matched code is on. This lets you define variables, call functions, or whatever else even if the code around the matched code would cause errors if you just rewrote them into where it was matched exactly. Whenever$ALLis used, code before doesn't need to be prefaced with$BEFOREand code after with$AFTERbecause rewriting them in place would either be the same or be undefined.$AFTER- See above.$INCR- Represents an integer that increments each time any rewrite rule is called. This allows you to define variables in your rewrite rules and not have any issues of the variable being overwritten or generating a compiler error from defining a variable with the same name twice.$foo:CONTAINING($bar, $baz, $etc)- This matches anything that contains the symbols in parentheses. The symbols in it would need to be matched on their own somewhere else in the same rewrite rule otherwise it would give a compiler error.See linked file for examples.