From 8480fd5393721e57ec3bc0171513f3239d193f6d Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 27 Sep 2021 21:21:29 -0400 Subject: Add support for ? predicates --- docs/implementation/vm.html | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'docs/implementation/vm.html') diff --git a/docs/implementation/vm.html b/docs/implementation/vm.html index 95c3ce5c..d25e39a1 100644 --- a/docs/implementation/vm.html +++ b/docs/implementation/vm.html @@ -273,7 +273,7 @@ 2A - +PRED 06 @@ -511,12 +511,14 @@

When a block is pushed with DFND, an instance of the block is created, with its parent frame set to be the frame of the currently-executing block. Setting the parent frame when the block is first seen, instead of when it's evaluated, is what distinguishes lexical from dynamic scoping. If it's an immediate block, it's evaluated immediately, and otherwise it's pushed onto the stack. When the block is evaluated, its frame is initialized using any arguments passed to it, the next instruction's index is pushed onto the return stack, and execution moves to the first instruction in the block. When the RETN instruction is encountered, an index is popped from the return stack and execution returns to this location. As an alternative to maintaining an explicit return stack, a block can be implemented as a native function that creates a new execution stack and returns the value in it when the RETN instruction is reached. This approach uses the implementation language's call stack for the return stack.

Local variables are manipulated with the VARO (or VARU) and VARM instructions, which load the value of a variable and a reference to it (see the next section) respectively. These instructions reference variables by frame depth and slot index. The frame depth indicates in which frame the variable is found: the current frame has depth 0, its block's parent frame has depth 1, and so on. The slot index is an index within that frame.

Slots should be initialized with some indication they are not yet defined. The variable can be defined with SETN only if it hasn't been defined yet, and can be accessed with VARO or VARU or modified with SETU, SETM, or SETC only if it has been defined.

-

Variable references: ARRM VARM SETN SETU SETM SETC SETH VFYM

+

Variable references: ARRM VARM SETN SETU SETM SETC

A variable reference indicates a particular frame slot in a way that's independent of the execution context. For example, it could be a pointer to the slot, or a reference to the frame along with the index of the slot. VARM pushes a variable reference to the stack.

A reference list is a list of variable references or reference lists. It's created with the ARRM instruction. In the Javascript VM there's no difference between a reference list and an ordinary BQN list other than the contents.

The SETN, SETU, SETM, and SETC instructions set a value for a reference. If the reference is to a variable, they simply set its value. For a reference list, the value needs to be destructured. It must be a list of the same length, and each reference in the reference list is set to the corresponding element of the value list.

SETM and SETC additionally need to get the current value of a reference. For a variable reference this is its current value (with an error if it's not defined yet); for a reference list it's a list of the values of each reference in the list.

+

Bodies: SETH VFYM PRED

SETH is a modification of SETN for use in header destructuring. It differs in that it doesn't place its result on the stack (making it more like SETN followed by POPS), and that if the assignment fails because the reference and value don't conform then it moves on to the next eligible body in the block rather than giving an error. VFYM converts a BQN value c to a special reference: assigning a value v to it should check if vc but do no assignment. Only SETH needs to accept these references, and it should treat non-matching values as failing assignment.

+

PRED drops the top value of the stack, but also checks whether it matches the number 1. If it does match, execution continues; if not, evaluation of the current body ends and evaluation moves to the next eligible body.

Namespaces: FLDO FLDM ALIM RETD

A namespace is the collection of variables in a particular scope, along with an association mapping some exported symbols (case- and underscore-normalized strings) to a subset of these. It can be represented using a frame for the variables, plus the variable name list and mask of exported variables from that block's properties in the bytecode. RETD finishes executing the block and returns the namespace for that execution.

The variable name list is split into a program-level list of names and a list of indices into these names: within-program field accesses can be done with the indices only while cross-program ones must use names. One way to check whether an access is cross-program is to compare the accessor's program-level name list with the one for the accessed namespace as references or pointers. Then a lookup should be performed as appropriate. A persistent lookup table is needed to make this efficient.

-- cgit v1.2.3