Interpreter improvements

[berekuk]

This implements the following items from #1932:

• Value-only stack
• Stack-compatible captures
• Mutable stack
• Mutable contexts

Performance benefits are around 20-25% for pure Squiggle code.

I expected more, but seems like we might be limited by frTypes performance.

Note: I'm using "compiler" for AST -> Expression tranformation, and "interpreter" for Expression -> Value transformation below.

Good things about this PR besides performance:

• more comments in compiler
• the algorithm that I use for captures will be useful for serializable lambdas
• this gets us closer to flattened IR, which we could later reuse for Wasm compilation
• I also separated FrameStack and StackTrace, which allowed me to get rid of that shift-by-one issue that I had to deal with in Error locations and stacktraces #1172 (comment)

Somewhat worrisome things about this PR:

• the algorithm for resolving names is now more complex, and in a sense more fragile (if we were working on a C compiler, I'd be worried about bugs that could cause security issues); I should write more tests for nested closures to check that everything is correct.
• the IR (Expression type) is now more condensed, and could be harder to debug; stringified IRs only contain stack references, I don't store names there anymore. We still carry AST values in the IR, but my guess is that we should stop doing that over time, and move to separately stored source maps.
• Mutable context means that the interpreter is also slightly harder to debug and implement now; also, rolling back captures and the stack after function calls feels weird, I guess I should move captures to the frameStack too.

Things to do before merge:

• fix decorators, I temporarily broke them
• clean up frame stack code
• fix tests that relied on expression serialization
• write more tests

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1f5972f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
quri-hub	✅ Ready (Inspect)	Visit Preview	Feb 13, 2024 7:55pm
quri-ui	✅ Ready (Inspect)	Visit Preview	Feb 13, 2024 7:55pm
squiggle-components	✅ Ready (Inspect)	Visit Preview	Feb 13, 2024 7:55pm
squiggle-website	✅ Ready (Inspect)	Visit Preview	Feb 13, 2024 7:55pm

[OAGr]

This is fairly complicated, and you understand this part of the codebase much better than I do, so I'll trust you on this one.

The output seems much better! (speedup, error messages, etc). Seems solid!

I'd like to better understand this part of the codebase later on, but I wouldn't wait on that for merging this. (Conflicts could be a pain, especially for large changes)