This might also be worth having as a dedicated instruction in the virtual machine. It can be implemented using an If instruction.

This operator would invoke Value::is_truthy() on the expression.

My current thought is a unary suffix operator:

<expr> ?

Currently, the CallInstrinsic instruction requires all the intrinsics to be known by the virtual machine. This is kind of weird, though, because the VM doesn't actually care about dynamic types.

The virtual machine should delegate the intrinsic instructions to the Environment, and Bud should be the owner of the current Intrinsic enum.

As I was a very basic reference for budasm, I once again had a slight distaste for the not instruction's implementation. Not still is implemented how I originally implemented the other bitwise operations: operate differently based on the type provided.

The reality is that bitwise and logical nots are completely different. ~1 and not 1 should yield values that have different truthiness, but most people think of 1 and true as being synonymous.

We should add a new operator, like tilde, in Bud to handle the bitwise specific operation, and not can be relegated to boolean operations only.

• Blocked by #9

Currently if a non-integer Value is encountered, the bitwise operators degrade to boolean operators (without short circuiting). Because these are dedicated operators, we should instead try converting the operands to integers and then performing the bitwise operation. This is more likely to catch programmatic errors than the other behavior.

With the VM being standalone, it would be nice to have the IR code be parseable. It's less important for the VM instructions to be able to be parsed directly from such a language, but given that the instructions are so similar, it might be possible to use the same AST to parse both types of instructions.

As per Discord, the virtual machine lacks some functionality that is needed to support closures. Specifically, there is no way to jump to an instruction and have another instruction jump back to the location jumped from. All instruction offsets are hard-coded and can't come from a variable.

In thinking about how I would want to design this, I want to design closure support with these constraints in mind:

• Pausing execution inside of a closure needs to be resumeable.
• Variable access needs to be protected: a closure should be able to access its own variables, but not be able to access other closure's variables. Closures should be able to access local variables from the function that is invoking the closure.

With these ideas in mind, I am thinking it would be great to give closures their own type of stack frame -- change StackFrame to an enum, and have Function and Closure variants. ValueOrSource would need a new option: ClosureVariable. When resolving a ClosureVariable, the stack can be checked to ensure a closure is executing and that the index is within the allocated region of the closure.

To invoke a closure, a new instruction is needed: CallClosure which takes an instruction offset and number of arguments on the stack.

If needed, the Return behavior can be updated based on whether execution is returning from a closure or from a function.

These are all notes from brainstorming about this idea -- the actual implementation may need to be different than this for reasons that won't be discovered until implementation begins.

The only hangup on implementing this is making it work with Map types. Ideally a for each loop over a map would yield a key and value, but we don't have a clean way for a function to return multiple values.

Early on in the design, the virtual machine allowed a function to return more than one value and for the returning function to receive more than one return value. It might be worth re-exploring that.

The virtual machine needs to be able to have an environment of nested namespaces/modules, allowing for functionality to be organized better.

The language will need support for finding named items within namespace.