Darryl Abbate

Note that the current lexical scoping rules will need to probably be chanegd to make closures work (i.e. make sense)

Since day 1, each `riff_code` object has maintained its own constants table, which forces a small amount of overhead since the VM uses a local variable for the constants tabled...

At the moment, there is only a single check for stack overflow at the very start of the interpreter loop. This obviously doesn't account for values being pushed onto the...

The lack of dedicated booleans (`true`, `false`) is kind of a [Norman door](https://uxdesign.cc/intro-to-ux-the-norman-door-61f8120b6086) for a high-level language. Adding support for booleans is trivial; the only thing to really figure out...

E.g. ```riff t = { [101] = 1, 2, // Index 102 foo = bar // t.foo or t["foo"] } ```

Self-explanatory ```riff fn foo(x = 1, y = 2) { // ... } ``` cc: #34

Each `riff_code` object contains "metadata" needed only during compilation. There may be a tiny performance boost available by decoupling these fields from the `riff_code` struct.

Todo: add benchmarking data Riff's stack-based VM is pretty fast, but gets outclassed by register-based VMs in benchmarks where a lot of values need to be pushed on and popped...

Codegen functions should return some kind of error status to the parser so the parser can report info such as the line number the error occured.

Depends on: - #49 | Opcode | Operand(s) | Operation | | ------ | ---------- | --------- | | `SETG` | `X` | `globals[K[X]] = SP[-1]` | | `SETL` |...