This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Refactor the interpreter to use Completion Record
types
#1540
Labels
enhancement
New feature or request
Right now when we're interpreting the AST we utilize
JsResult
as a wrapper for any error that originates on execution. This has its advantages; we can propagate type errors andthrow
errors with?
and return any value generated from a native function with ease. However, #672 showed us that having no distinction between a value returned from a native function and a value returned from AST interpretation is suboptimal.The spec solves this problem with
Completion Records
, which are a way to separate values generated from native functions and values generated from the execution of Javascript code.This technique also allows us to eliminate
InterpreterState
from theContext
, essentially removing state that we needed to maintain by hand, like in:boa/boa/src/syntax/ast/node/return_smt/mod.rs
Lines 70 to 73 in a11a8a9
or
boa/boa/src/syntax/ast/node/statement_list/mod.rs
Lines 121 to 123 in a11a8a9
To implement
CompletionRecords
we would need to make a big refactor to the AST. Here's a non-exhaustive list in an arbitrary order of the required tasks:CompletionRecord
struct type with its associated methods from the specrun
from theExecutable
trait return aJsResult<CompletionRecord>
.CompletionRecord
of every AST node evaluation.InterpreterState
from theContext
type. (We can reuse the type as the[[Type]]
field of aCompletionRecord
)The text was updated successfully, but these errors were encountered: