Using Grammar in Storm
This tutorial shows how to use the Syntax Language together with Basic Storm to parse simple arithmetic expressions. This tutorial involves context-free grammars and regular expressions. It assumes that you have some knowledge of these concepts, as the tutorial focuses on how to use context-free grammars and regular expressions in Storm.
As with the other tutorials, the code produced by this tutorial is available in
root/tutorials/grammar. You can run it by typing tutorials:grammar:main in the Basic Storm
interactive top-loop.
Setup
First, we need somewhere to work. Create an empty directory somewhere on your system. The name does
not matter too much, but it is easier if you avoid spaces and numbers in the name since it will be
used as a package name in Storm. For example, use the name grammar. Then, open a terminal and
change into the directory you just created. This makes it possible to run the code we will write by
typing the following in the terminal:
storm .
Note that it will currently only start the top-loop since we have not yet defined a main function.
Grammar for Expressions
In this tutorial, we will create a simple grammar for parsing simple arithmetic expressions. We
start by writing the grammar in the Syntax Language. Create a file with the extension .bnf (for
example, expr.bnf, but the name does not matter) and open it in your editor.
We start by specifying the meaning of the , and ~ separators in the file. We do this using the
optional delimiter and required delimiter directives respectively:
optional delimiter = SOptDelimiter; required delimiter = SReqDelimiter;
This tells the system that whenever , appears, it should use the rule SOptDelimiter, and
whenever ~ appears, it should use the rule SReqDelimiter. These rules can have any name. We
could even use the rules from Basic Storm if we wished by specifying lang.bs.SDelimiter and
lang.bs.SRequiredDelimiter.
Since we have told the system to use SOptDelimiter and SReqDelimiter, we also need to define
them. We start by defining the rules themselves. Since they are used as delimiters, we are not
interested in capturing anything in these rules. Therefore we declare them as accepting no
parameters, and returning void:
void SOptDelimiter(); void SReqDelimiter();
We must also define productions for these rules. Currently, the rules exists but does not match any
strings (not even the empty string). This means that wnenever , or ~ are used in the grammar,
the parser will reject all strings, which is not what we want.
To avoid this, we define two productions as follows. Each production contains a single regular expression. The first one matches zero or more whitespace, and the second matches one or more whitespace:
SOptDelimiter : "[ \n\r\t]*"; SReqDelimiter : "[ \n\r\t]+";
With the delimiters out of the way, we can start writing the actual grammar. Since we have defined
the optional delimiter, we can use , in any place where spaces may appear. This makes the
grammar more compact and easy to read, since we do not have to write SOptDelimiter all over the
grammar.
At this point it might be worth talking about naming. As you can see, all productions have names
that start with an S. This is in no way required by Storm or the Syntax Language. It is, however,
convenient to prefix the names of things in the Syntax Language with S for two reasons:
- It makes it very clear when we are referring to things in the Syntax Language.
-
It avoids name collisions between types generated for the parse tree, and types for other
representations. For example, Basic Storm has a type
Exprthat represents a node in the Abstract Syntax Tree (AST). The syntax also has a rule that corresponds to an expression. This rule is namedSExpr, since the type generated for the parse tree would otherwise have the same name as the corresponding AST node.
In this example we do not have other representations, so we could skip the S prefix. However, we
use it here to be consistent with the naming in other parts of Storm.
With this in mind, we can now write the grammar for parsing simple expressions. The grammar supports
+, -, *, and /. We split the grammar into three "layers" so that the different operators
have the correct priority.
The first rule, SExpr represents an entire expression. We define it as follows:
void SExpr(); SExpr : SExpr, "\+", SProduct; SExpr : SExpr, "-", SProduct; SExpr : SProduct;
The first line defines the rule itself. For now, we do not worry about the parameters and return
type since we are only interested in parsing at the moment. The second line defines a production for
the SExpr line. It states that an expression can be an expression, followed by a + sign,
followed by a SProduct. Each of these three parts may be separated by zero or more spaces since
they are delimited by commas (and due to our definition of the optional delimiter). Note that we
need to escape the + character in the regular expression, since + has a special meaning in
regular expressions.
The third line is similar to the second, except that it defines subtraction instead of addition.
Finally, the fourth and last line states that an expression may simple be a SProduction. This
allows us to parse expressions that contains no + or - operators at the topmost level.
Next up is the SProduct rule. It represents a part of an expression that contains operators that
have higher priority than + and -. In our case, this is * and /. It has the same structure
as the rules and productions for SExpr:
void SProduct(); SProduct : SProduct, "\*", SAtom; SProduct : SProduct, "/", SAtom; SProduct : SAtom;
Finally, the rule SAtom represents parts of an expression that are atomic with regards to
operators. In our case, it matches numbers (the second line), and expressions inside of parentheses:
void SAtom(); SAtom : "[0-9]+"; SAtom : "(", SExpr, ")";
With all of these parts, our grammar is complete. We can now focus on how the grammar is used from
Basic Storm. Therefore, we need to create a file with the extension .bs to store or Basic Storm
code. For example, call the file expr.bs, but the name does not matter.
In the file, we add the following content to test the grammar:
use core:lang; // for Parser use core:io; // for Url void eval(Str expr) on Compiler { Parser<SExpr> parser; parser.parse(expr, Url()); print(parser.infoTree().format()); } void main() on Compiler { eval("1 + 2"); }
The code first imports the package core:lang so that we can access the type Parser conveniently.
We also import core:io to access Url conveniently.
Next, we define the function eval that we will develop so that it evaluates an expression. Since
the parser and the grammar are all actors that execute on the Compiler thread, we declare this
function to run on the Compiler thread as well to avoid expensive thread switches.
Inside the eval function, the first step is to create a parser instance. The name of the starting
production is specified as a parameter to the type (just as with Array). So, Parser<SExpr> means
that we create a parser that starts in the rule SExpr. The parser automatically imports all
productions in the package that SExpr resides in.
After creating a parser, we can parse the input string by calling the parse member. It accepts two
parameters: first the string to be parsed, and then the path of the file that the string originates
from. Since we did not read our string from a file, we simply pass an empty Url. This is not a
problem since the parser only uses the second parameter for indicating the position of errors.
When the parse member has finished it work, we can extract the parse tree from the parser. For
now, we use the member infoTree for this. To see the tree in a textual representation, we call
format on the tree and finally print it.
Finally, to run the code conveniently, we define a main function that simply calls eval with an
example expression to see if our program works correctly. This means that we can run the example
from the terminal by running: storm . (assuming we are in the directory with that contains our two
files). For the expression 1 + 2, this produces output like below (the numbers after @ may
differ depending on the order of the productions):
{
production: @ 2 of SExpr
1 -> {
production: @ 4 of SExpr
1 -> {
production: @ 7 of SProduct
1 -> {
production: @ 8 of SAtom
1 -> '1' (matches "-?[0-9]+")
}
}
}
1 -> {
production: @ 0 of SOptDelimiter
1 -> ' ' (matches "[ \n\r\t]*")
} (delimiter)
1 -> '+' (matches "\+")
1 -> {
production: @ 0 of SOptDelimiter
1 -> ' ' (matches "[ \n\r\t]*")
} (delimiter)
1 -> {
production: @ 7 of SProduct
1 -> {
production: @ 8 of SAtom
1 -> '2' (matches "-?[0-9]+")
}
}
}
The output above shows exactly which productions the parser matched. The names that start with @
are the anonymous names of the productions in our syntax. If we give them a name (by adding =
<name> before the semicolon), we can see the names of the productions as well. It is, however, not
very easy to read since it contains too many details.
Let's try to improve the readability by asking the parser for a parse tree rather than an info tree.
We can do this by replacing print(parser.infoTree().format()) with print(parser.tree().toS()).
This gives us the following output:
{ ./(0-5)
grammar.SExpr -> grammar.@ 3
}
This time the parse tree is too small. It only contains one node that corresponds to the starting
production. The line grammar.SExpr -> grammar.@ 3 means that we printed a node that corresponds to
the production grammar.@ 3 that extens the rule grammar.SExpr.
Binding Tokens to Variables
The reason why only one node appeared is that the Syntax Language only saves subtrees that are bound to variables. To bind subtrees to variables, we can simply add a name after the token we wish to save. In our case, we can do like this:
void SExpr(); SExpr : SProduct p; SExpr : SExpr l, "\+", SProduct r; SExpr : SExpr l, "-", SProduct r; void SProduct(); SProduct : SAtom a; SProduct : SProduct l, "\*", SAtom r; SProduct : SProduct l, "/", SAtom r; void SAtom(); SAtom : "-?[0-9]+" nr; SAtom : "(", SExpr e, ")";
If we run the program once more (using storm .), we get a more reasonable output:
{ ./(0-5)
grammar.SExpr -> grammar.@ 2
l : { ./(0-1)
grammar.SExpr -> grammar.@ 4
p : { ./(0-1)
grammar.SProduct -> grammar.@ 7
a : { ./(0-1)
grammar.SAtom -> grammar.@ 8
nr : 1@./(0-1)
}
}
}
r : { ./(4-5)
grammar.SProduct -> grammar.@ 7
a : { ./(4-5)
grammar.SAtom -> grammar.@ 8
nr : 2@./(4-5)
}
}
}
Lines that start with { indicate the start of a node that corresponds to a production. Right after
the { is the location in the input that matched the node. In the case of the root note, the entire
string was matched, so (0-5) is printed. The part before (./) is the Url we passed to parse.
The empty Url is printed as ./ since it is a relative path to the current directory. The first
line in each node is the name of the rule and production that were matched (as we saw above). Any
remaining lines are the variables that are bound. In the topmost node, we can for example see that
the variables l and r are bound, and contains other nodes. Eventually, we will see variables
that are bound to things that are indicated as 1@./(0-1) for example. This is the representation
of text that matches a regular expression. In the case of 1@./(0-1), it represent that the text
1 was matched at the source location after the @ (i.e. in ./, characters 0-1).
At this point it is a good idea to test some different expressions and see how the corresponding parse trees look.
Disallow Partial Matches
One thing you might note is that the parse succeeds even though the whole string is not correct. For
example, parsing 1 + a succeeds, but the parser only matches the first 1. The parser behaves
this way to allow parsing prefixes of strings conveniently. As long as the parser manages to find a
match, it treats the parse as a success (this is why 1 + a works, but not a + 1 for example). It
is, however, easy to check whether it succeeded in parsing the entire string or not by calling the
hasError member. This function returns true if the parser has found an error anywhere in the
string, and false otherwise. It can be used like below:
void eval(Str expr) on Compiler { Parser<SExpr> parser; parser.parse(expr, Url()); if (parser.hasError()) throw parser.error(); print(parser.tree().toS()); }
Interacting with the Parse Tree
Just parsing may be fun, but we would also like to use the results of the parse for something useful. Since rules and productions appear as classes in Basic Storm, let's try to inspect it that way.
To be able to access individual productions from Basic Storm, we must first give them a name. We do
this by appending a name to the end of the productions. As a start, we only do this for the
productions for SExpr. We name the first one Add, the second one Subtract, and the third one
Product as below:
void SExpr(); SExpr : SExpr l, "\+", SProduct r = Add; SExpr : SExpr l, "-", SProduct r = Sub; SExpr : SProduct p = Product;
The only difference from before is that the productions have a name that is not anonymous. This is
reflected in the textual representation of the parse tree. If we run the code we had before, we will
now see the names appear in the textual representation of the tree. The first line in the root node
contains grammar.SExpr -> grammar.Add instead of grammar.SExpr -> grammar.@ 2, which is a bit
easier to understand.
{ ./(0-5)
grammar.SExpr -> grammar.Add
l : { ./(0-1)
grammar.SExpr -> grammar.Product
p : { ./(0-1)
grammar.SProduct -> grammar.@ 4
a : { ./(0-1)
grammar.SAtom -> grammar.@ 5
nr : 1@./(0-1)
}
}
}
r : { ./(4-5)
grammar.SProduct -> grammar.@ 4
a : { ./(4-5)
grammar.SAtom -> grammar.@ 5
nr : 2@./(4-5)
}
}
}
These names also means that we can inspect the nodes from Basic Storm. Since both rules and expressions appear as types to Basic Storm (and most other languages as well), and that the production-types inherit from the corresponding rule-type. This means that we can inspect the parse tree simply by using a downcast.
We first store the result of parser.tree() in a variable. The result has the type SExpr (the
same as the parameter to the Parser) since that is the rule we started parsing at:
SExpr tree = parser.tree();
The SExpr type is abstract since it corresponds to a rule. That means that it will contain one of
the subclasses to SExpr. In our case we have three subclasses, one for each of the productions
Add, Subtract, and Product. We can check which one it is using the as operator in an
if-statement:
if (tree as Add) { // ... }
Remember that tree will have the type Add inside the if-statement. This means that we can
access the subtrees that correspond to the bound tokens as member variables inside tree. For
example, we can print the left- and right-hand sides as follows:
print("Addition of:");
print(tree.l.toS());
print("and:");
print(tree.r.toS());
If we do the same thing for the remaining productions, we get the following implementation of
eval:
void eval(Str expr) on Compiler { Parser<SExpr> parser; parser.parse(expr, Url()); SExpr tree = parser.tree(); if (tree as Add) { print("Addition of:"); print(tree.l.toS()); print("and:"); print(tree.r.toS()); } else if (tree as Sub) { print("Subtraction of:"); print(tree.l.toS()); print("and:"); print(tree.r.toS()); } else if (tree as Product) { print("Just a product:"); print(tree.p.toS()); } }
As we can see, this quickly gets tedious to maintain. We have to write code that is tightly coupled with the grammar just to extract the meaning of the parse. This structure also makes it difficult to extend the grammar, since adding a new production would require adding another branch to the long if-statements somewhere in the system.
Using Syntax Transforms
Due to the problems we saw above, it is not common to use names and type-casts to inspect the grammar in Storm. Instead, the Syntax Language provides a mechanism, called syntax transforms, to specify the semantics of the grammar along with the grammar itself. This allows the Syntax Lanugage to generate code that traverses the grammar and transforms it into a more convenient representation. Since this representation is written alongside the grammar, it also has the benefit that it allows easy extension from other places.
In this tutorial, we will not use the grammar to generate an AST, which is often the case for languages in Storm. Rather, we will use the syntax transforms to actually evaluate the parsed expressions directly.
Since we will not need the production names anymore, we remove them an replace them with syntax
transforms instead. We start by modifying the rule definitions. Since we will use the transforms to
evaluate expressions, we want to return a value from the transform functions. To simplify the
semantics, we limit ourselves to integers and thereby replace the return type with Int:
Int SExpr(); Int SProduct(); Int SAtom();
We also need to modify the productions to actually return a value. This is done by adding an arrow
(=>) followed by a simple expression that should be evaluated to create the value. Note that these
simple expressions in the Syntax Language may only consist of a single function call, a single
constructor call, or the name of a variable. We start with the productions for SExpr. The first
one (for addition) needs to compute the sum of the left hand side and right hand side of the +.
Since we have declared that both SExpr and SProduct return an Int, both l and r are
integers, which means that we can simply call the + operator in Storm by adding => +(l, r) as
follows:
SExpr => +(l, r) : SExpr l, "\+", SProduct r;
This means that whenever the rule is matched, we will first evaluate the left-hand side and bind it
to l, then the right-hand side and bind it to r, and finally call +(l, r) (which is the same
as l + r in Basic Storm), bind it to me, and finally return it to the caller.
We do the same thing for -:
SExpr => -(l, r) : SExpr l, "-", SProduct r;
For the last production in SExpr, we do not need to perform any computations. We simply need to
forward the value of the SProduct match. We can do that by simply specifying the variable we wish
to return after the arrow (=>) like so:
SExpr => p : SProduct p;
The three productions for SProduct are nearly identical to the productions in SExpr and can be
modified in the same way:
SProduct => *(l, r) : SProduct l, "\*", SAtom r; SProduct => /(l, r) : SProduct l, "/", SAtom r; SProduct => a : SAtom a;
Finally, we need to modify the productions for SAtom. The first one matches numbers. However,
since we bind the text that matched the regular expression to the variable nr it will have the
type Str, but we need to return an Int. Luckily, the Str class has a member called toInt
that performs the conversion for us. To call it, we can add => toInt(nr) to the production as
follows:
SAtom => toInt(nr) : "-?[0-9]+" nr;
The second and last production for handling parentheses is similar to the ones in SExpr and
SProduct. Since this production is only used to enforce the correct order of operations, it is
enough to simply return the value of e:
SAtom => e : "(", SExpr e, ")";
To summarize, the grammar should now look like as follows:
Int SExpr(); SExpr => +(l, r) : SExpr l, "\+", SProduct r; SExpr => -(l, r) : SExpr l, "-", SProduct r; SExpr => p : SProduct p; Int SProduct(); SProduct => *(l, r) : SProduct l, "\*", SAtom r; SProduct => /(l, r) : SProduct l, "/", SAtom r; SProduct => a : SAtom a; Int SAtom(); SAtom => toInt(nr) : "-?[0-9]+" nr; SAtom => e : "(", SExpr e, ")";
We can now modify the eval function in Basic Storm to use the syntax transforms. This is done by
calling the transform member of the root node of the tree. This causes the transforms for the root
node to be evaluated. Since the root node uses the value of other nodes, this will cause the
relevant parts of the parse tree to be evaluated. Finally, we simply print the result:
void eval(Str expr) on Compiler { Parser<SExpr> parser; parser.parse(expr, Url()); SExpr tree = parser.tree(); Int result = tree.transform(); print("${expr} evaluated to ${result}"); }
Experiment with a few different expressions to see how the system works. It might also be
interesting to add other operators to the syntax. For example, it is fairly easy to add min(x, y)
and max(x, y) to the grammar by adding new productions to the SAtom production.
Parameters in the Syntax
So far, we have not needed to use parameters to productions in the syntax. To illustrate this, let's
add support for variables to our small language. The goal is to provide the syntax transforms with a
data structure, VarList, that contains a collection of named values that should be usable. This
allows writing expressions like: a * 2, or x + y * 2, for example.
First, we define a class that stores our variables:
class VarList { Str->Int values; void put(Str name, Int value) { values.put(name, value); } Int get(Str name) { if (x = values.at(name)) { x; } else { throw NoVariable(name); } } }
As we can see, the class is essentially a thin wrapper around a regular Map. It would be
sufficient for our purposes to just use a Map, but creating a wrapper in this manner lets us
customize the get function to throw a nicer error, and makes it easier to extend it in the future
with custom operations that might be required by the syntax.
Since we throw a custom exception in the get function, we also need to define the exception class:
class NoVariable extends Exception { Str variable; init(Str variable) { init { variable = variable; } } void message(StrBuf out) : override { out << "No variable named " << variable << " is defined."; } }
After doing this, we can start extending the grammar. To use variables we add a new production to
the SAtom rule:
SAtom : "[A-Za-z]+" name;
This rule matches a string of one or more letters and binds it to the variable name. However, we
run into problems when trying to implement the transform for it. We wish to call the get function
of a VarList object, but we do not have access to such an object. To solve the problem, we can add
a parameter to the SAtom rule as follows:
Int SAtom(VarList vars);
This means that whenever the transform for an SAtom is called, the caller needs to supply a list
of variables. This makes it possible to write the transform function for our new production as
follows:
SAtom => get(vars, name) : "[A-Za-z]+" name;
This is good so far, but if we try to run the code at this point we will get an error that says:
"Can not transform a grammar.SAtom with parameters: ()". This means that we have not passed all
required parameters to the transform function in our grammar. This is indeed true, since we are
transforming SAtom in the productions for SProduct for example. To solve this problem, we need
to update our grammar so that both SExpr and SProduct accept a VarList as a parameter, and
passes it forward. To do this, add parentheses after the rule names in the productions and add the
name of the variable that shall be passed as a parameter. This makes the rules look like function
calls. After doing this modification, the grammar looks like this:
Int SExpr(VarList vars); SExpr => p : SProduct(vars) p; SExpr => +(l, r) : SExpr(vars) l, "\+", SProduct(vars) r; SExpr => -(l, r) : SExpr(vars) l, "-", SProduct(vars) r; Int SProduct(VarList vars); SProduct => a : SAtom(vars) a; SProduct => *(l, r) : SProduct(vars) l, "\*", SAtom(vars) r; SProduct => /(l, r) : SProduct(vars) l, "/", SAtom(vars) r; Int SAtom(VarList vars); SAtom => toInt(nr) : "-?[0-9]+" nr; SAtom => e : "(", SExpr(vars) e, ")"; SAtom => get(vars, name) : "[A-Za-z]+" name;
Finally, we need to update the code in the eval function to pass a VarList object as a
parameter. To be able to test our implementation, we also add the variable ans to the list as
well:
void eval(Str expr) { Parser<SExpr> parser; parser.parse(expr, Url()); SExpr tree = parser.tree(); VarList variables; variables.put("ans", 42); Int result = tree.transform(variables); print("${expr} evaluated to ${result}"); }
Now, we can test the implementation by evaluating an expression like 1 + ans by modifying main:
void main() { eval("1 + ans"); }
Transforms with Side-Effects
So far, we are only able to use pre-defined variables, not define new ones. Lets extend the language
further to make it possible to create new variables from within the language. The goal is to create
a language where we can specify one or more statements separated by commas. A statement is either
an assignment (<variable> = <expression>) or just an expression. The language evaluates all
statements in order, and records the value of all statements that were not assignments. For example,
the string:
a = 20, b = a - 10, a + b, b - a
Produces the result: 30, 10.
To implement the grammar for this, we start by defining a new rule, SStmt, that accepts a variable
list like before. The rule has two productions, one for an assignment, and one for a plain
expression:
void SStmt(VarList vars); SStmt : SExpr(vars) expr; SStmt : "[A-Za-z]+" name, "=", SExpr(vars) value;
We can then create a rule that matches a series of these values: SStmtList:
void SStmtList(VarList vars); SStmtList : SStmt(vars) - (, ",", SStmt(vars))*;
The production that matches the list might look a bit complex at first since it uses the repetition
syntax. The goal is to match SStmt one or more times, but with a comma between each occurrence.
First, it matches SStmt once, outside the repetition syntax. Then it specifies the - separator
since we do not want to match anything more before the parenthesis. The parenthesis is matched zero
or more times since it ends with a *. Each time it matches an optional whitespace, a comma,
another optional whitespace, followed by a SStmt.
To illustrate the behavior, let's expand the repetiton a number of times to see the pattern clearer:
SStmtList : SStmt(vars); // Repeated 0 times SStmtList : SStmt(vars), ",", SStmt(vars); // 1 time SStmtList : SStmt(vars), ",", SStmt(vars), ",", SStmt(vars); // 2 times // ...
The problem that remains is to write syntax transforms that implement our desired behavior. The
production for the assignment is the easiest one, so let's start there. For this production, we can
simply store the value of the new variable by calling put in our VarList class:
SStmt => put(vars, name, value) : "[A-Za-z]+" value, "=", SExpr(vars) value;
The other productions are a bit trickier. The goal is to save the value of all non-assignment
expressions in an array. So let's start by updating the return type of SStmtList. Note that it is
not possible to use the shorthand Int[] in the Syntax Language:
Array<Int> SStmtList();
Then, we need to write the the syntax transform in the SStmtList transform. We can start by simply
creating an array:
SStmtList => Array<Int>() : SStmt(vars) - (, ",", SStmt(vars))*;
This will work, but the array will always be empty since we never added anything to it. One option
to do this would be to use the -> syntax to call the push member of the array for each SStmt.
This can be done as follows:
SStmtList => Array<Int>() : SStmt(vars) -> push - (, ",", SStmt(vars) -> push)*;
This does, however not work in this situation, as we only wish to add the non-assignment
statements. The rule above would add all statements. It would also require that the SStmt rule
would return an Int, which is not currently the case.
Instead, we can pass the array as a parameter to the SStmt rule, and let the productions there add
themselves to the array whenever it is suitable. As such, we modify the rule SStmt as follows:
void SStmt(Array<Int> appendTo, VarList vars);
This means that we need to modify the SStmtList production to pass the array to the SStmt rule.
For this, we utilize the fact that the expression to be returned is bound as the variable me in
the rule. We can thereby use me to pass it to SStmt:
SStmtList => Array<Int>() : SStmt(me, vars) - (, ",", SStmt(me, vars))*;
Finally, we need to actually add the result of expressions to the array. There are two ways in which
we can do this. The first one is to call push in the expression after the arrow as follows:
SStmt => push(appendTo, expr) : SExpr(vars) expr;
Another option that abuses the semantics of the Syntax Language slightly is to utilize the fact that
SStmt returns void, and we may therefore bind anything to the variable me to be able to use
the -> syntax. For our current purposes they are equivalent, but this approach has the benefit
that it is possible to call members multiple times in the same production. For example, this is
particularly useful when a production contains repetition:
SStmt => appendTo : SExpr(vars) -> push;
In the end, the new grammar we added to the file is the following:
void SStmt(Array<Int> appendTo, VarList vars); SStmt => appendTo : SExpr(vars) -> push; SStmt => put(vars, name, value) : "[A-Za-z]+" name, "=", SExpr(vars) value; Array<Int> SStmtList(VarList vars); SStmtList => Array<Int>() : SStmt(me, vars) - (, ",", SStmt(me, vars))*;
With the grammar done, the only remaining thing is to update the eval function once more to use
our revised syntax:
void eval(Str expr) on Compiler { Parser<SStmtList> parser; parser.parse(expr, Url()); if (parser.hasError()) throw parser.error(); SStmtList tree = parser.tree(); VarList variables; Array<Int> results = tree.transform(variables); print("Results: ${results}"); }
We can then modify main to verify that our implementation seems to work:
void main() on Compiler { eval("a = 20, b = a - 10, a + b, a - b"); }