Add a visualization of two ASTs

Signed-off-by: Danila Fedorin <danila.fedorin@gmail.com>
This commit is contained in:
Danila Fedorin 2024-11-03 17:06:19 -08:00
parent 615aeb72da
commit ee13409b33

View File

@ -117,11 +117,31 @@ is called an [Abstract Syntax Tree](https://en.wikipedia.org/wiki/Abstract_synta
Notably, though `2-(x+y)` has parentheses, our grammar above does not include Notably, though `2-(x+y)` has parentheses, our grammar above does not include
include them as a case. The reason for this is that the structure of an include them as a case. The reason for this is that the structure of an
abstract syntax tree is sufficient to encode the order in which the operations abstract syntax tree is sufficient to encode the order in which the operations
should be evaluated. should be evaluated. Since I lack a nice way of drawing ASTs, I will use
an ASCII drawing to show an example.
{{< todo >}} ```
Probably two drawings of differently-associated ASTs here. Expression: 2 - (x+y)
{{< /todo >}} (-)
/ \
2 (+)
/ \
x y
Expression: (2-x) + y
(+)
/ \
(-) y
/ \
2 x
```
Above, in the first AST, `(+)` is a child of the `(-)` node, which means
that it's a sub-expression. As a result, that subexpression is evaluated first,
before evaluating `(-)`, and so, the AST expresents `2-(x+y)`. In the other
example, `(-)` is a child of `(+)`, and is therefore evaluated first. The resulting
association encoded by that AST is `(2-x)+y`.
To an Agda programmer, the one-of-four-things definition above should read To an Agda programmer, the one-of-four-things definition above should read
quite similarly to the definition of an algebraic data type. Indeed, this quite similarly to the definition of an algebraic data type. Indeed, this