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
Currently we determine the number of arguments to a function statically. This prevents cool things like variable numbers of arguments and, indirectly, multiple return values. Here's how we can improve it:
When we encounter an infix left paren (i.e. the start of a call expression), we'll add an opcode called OP_PREP_FOR_CALL, which will store the current stack position in the function state. This stack position will be the position after the function we'll be calling.
After that opcode will be the evaluation of all the arguments, and then the OP_CALL. This means we can just compare the stack position at call time with the stored position from prep for call to see how many arguments we actually have. This means that the number of arguments can be dynamic, without incurring much overhead. In fact, while we add an extra operation, we can remove the argument to OP_CALL so the size of a function call is smaller by 32 bits.
This means that splatting an array into the arguments of a function is just a matter of pushing all the elements of the array to the stack, and if calling a function leaves behind multiple values (multiple returns), that's fine too.
The text was updated successfully, but these errors were encountered:
p7g
linked a pull request
Jul 26, 2020
that will
close
this issue
Currently we determine the number of arguments to a function statically. This prevents cool things like variable numbers of arguments and, indirectly, multiple return values. Here's how we can improve it:
When we encounter an infix left paren (i.e. the start of a call expression), we'll add an opcode called
OP_PREP_FOR_CALL
, which will store the current stack position in the function state. This stack position will be the position after the function we'll be calling.After that opcode will be the evaluation of all the arguments, and then the
OP_CALL
. This means we can just compare the stack position at call time with the stored position from prep for call to see how many arguments we actually have. This means that the number of arguments can be dynamic, without incurring much overhead. In fact, while we add an extra operation, we can remove the argument toOP_CALL
so the size of a function call is smaller by 32 bits.This means that splatting an array into the arguments of a function is just a matter of pushing all the elements of the array to the stack, and if calling a function leaves behind multiple values (multiple returns), that's fine too.
The text was updated successfully, but these errors were encountered: