moar thoughts

thoughts.md

@@ -72,3 +72,21 @@ Because the pattern match will actually have to be a little Chumsky parser guy (
 ### On performance
 The Rust tree-walk interpreter is something like two orders of magnitude faster than the Janet interpreter.
 So in that sense, I think it's a worthwhile middle ground to effectively publish this first, easier-to-develop approach, and then to work on a bytecode VM later.
+
+It's worth noting that my approach to this first tree-walk interpreter still leaves a lot on the table for optimization: the `Value` enum is 64 _bytes_.
+This is because `imbl::Vector`s are 64 bytes.
+I'm trying to ensure opportunistic mutation throughout, but I have found it hard with dicts.
+This sort of thing.
+
+Finally, it's clear that some perf testing will be necessary to determine the final arrangement of things.
+Will `box`ing things to get heap pointers help? 
+Or will the extra indirection cost more speed than even if we squeeze `Value`'s size down to 8 bytes?
+Will `box`ing lists, etc., mung up how `imbl` does refcounting and opportunistic mutation?
+There are things like `tinyvec` which does some of the dark magic around allocating that might make using tuples easier to manage?
+
+### On parsing in Ludus
+I've been thinking about Ludus's built-in parsing capabilities.
+Using the interpolition-style string pattern matching parsing for ELIZA makes a lot of sense, but we need something more robust for, say, a Lisp.
+Looking at this, I think that Janet's builtin PEG parsing might be a much more interesting solution than just about anything else.
+I'm pretty sure I can make a slow, but user-friendly-enough version of that that works in Ludus.
+(Famous last words.)