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
Because we don't do the same for blocks (if,while etc) any let values we create in blocks are added to the current environment, which will be the outer function most likely. This means the following JS works..
When a Block or CaseBlock is evaluated a new declarative Environment Record is created and bindings for each block scoped variable, constant, function, or class declared in the block are instantiated in the Environment Record.
The process here is to create a new_declarative_environment when we hit a block and set that to the current environment, popping it off when we reach the end of our block. A potential bug this will cause is putting var declarations into the same scope, so we need to make sure vars still go into the function scope above.
low level
new_declaration_environment is already exposed here. Bring it into exec.rs so that it can be used similar to how new_function_environment is used.
lexical_environment.rs will need a way of setting bindings to the nearest function environment, rather than the current environment (to support var)
The text was updated successfully, but these errors were encountered:
* Implement block scoped variable declarations
`const` and `let` are now scoped to the block, while `var` is scoped to
the surronding function (or global).
Another bigger change is that all tests have been changed to use `var`
instead of `let` or `const`. This is because every time `forward` is
called with some new Javascript to evaluate, we parse it as a block,
hence variables can only persist across calls to `forward` if they are
defined using `var`. I assume it is intentional to parse each call as a
separate block, because a block is the only `ExprDef` which can contain
multiple statements.
Closes#39
* Prefer environment parent over environment_stack
Instead of iterating over the `environment_stack` we rather use
`get_outer_environment` as it will be a better fit when asyncronous
functions are implemented.
* Ensure variable from outer scope is assigned
Variables that are defined outside a block should be changeable within
the scope. Just because variable is undefined does not mean it is not
initialized.
When we step into a new function, we create a
new_function_environment
https://github.com/jasonwilliams/boa/blob/master/src/lib/exec.rs#L110Because we don't do the same for blocks (if,while etc) any let values we create in blocks are added to the current environment, which will be the outer function most likely. This means the following JS works..
What does the specification say?
When a Block or CaseBlock is evaluated a new declarative Environment Record is created and bindings for each block scoped variable, constant, function, or class declared in the block are instantiated in the Environment Record.
https://tc39.es/ecma262/#sec-blockdeclarationinstantiation
high level task
The process here is to create a
new_declarative_environment
when we hit a block and set that to the current environment, popping it off when we reach the end of our block. A potential bug this will cause is puttingvar
declarations into the same scope, so we need to make surevars
still go into the function scope above.low level
new_function_environment
is used.var
)The text was updated successfully, but these errors were encountered: