You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That is, the checker checks and annotates the AST with information available statically and the evaluator evaluates the annotated AST. This poses two problems:
The AST is walked twice, meaning a change in the AST structs usually affect three places: the parser, the checker and the evaluator.
Getting the types right is tedious. The type of the annotation is declared in the eval package, AST nodes in parse. eval imports parse; since golang forbids cyclic imports, parse cannot import eval and AST nodes cannot contain annotation types directly. To work around this, all annotations are typed interface{} and the Checker and Evaluator make type assertions everywhere.
The plan is to introduce a new component, a compiler that takes up the role of the checker and much of the evaluator. Instead of checking and annotating the AST, the compiler performs deferred evaluation of the AST. For instance, a factor is evaluated into a func(*Evaluator) []Value, where currently, the evaluator evaluates it into a []Value. Similar things apply to all levels of the AST, from terms to chunks.
This would solve the aforementioned problems, but by using closures extensively it could also make debugging a bit harder.
The text was updated successfully, but these errors were encountered:
Current flow of source code:
That is, the checker checks and annotates the AST with information available statically and the evaluator evaluates the annotated AST. This poses two problems:
eval
package, AST nodes inparse
.eval
importsparse
; since golang forbids cyclic imports,parse
cannot importeval
and AST nodes cannot contain annotation types directly. To work around this, all annotations are typedinterface{}
and the Checker and Evaluator make type assertions everywhere.The plan is to introduce a new component, a compiler that takes up the role of the checker and much of the evaluator. Instead of checking and annotating the AST, the compiler performs deferred evaluation of the AST. For instance, a factor is evaluated into a
func(*Evaluator) []Value
, where currently, the evaluator evaluates it into a[]Value
. Similar things apply to all levels of the AST, from terms to chunks.This would solve the aforementioned problems, but by using closures extensively it could also make debugging a bit harder.
The text was updated successfully, but these errors were encountered: