write a few thoughts

thoughts.md

@@ -49,10 +49,26 @@ Tuples should be refcounted for now.
 * `chumsky` for parsing
 * `ariadne` for parsing errors
 * `imbl` for persistent data structures
-* `boxing` for NaN boxing
+* `boxing` for NaN boxing (eventually?)
-* `tailcall` for tail recursion
+* ~~`tailcall` for tail recursion~~ This only works for simple recursion, and we need mutual recursion.
 
 We additionally might want crates for:
 * processes/actors, although given that Ludus will be single-threaded for the forseeable future, it may be lighter weight to just write my own `process` abstraction
 * in that case, we will need a ringbuffer, `ringbuf`
 
+### On string interpolation
+#### Which is proving rather harder to handle than I expected
+I'm trying to use Chumsky to do this, but it's weirdly much harder to model with Chumsky's parer combinators than I expected. 
+I suspect the thing to do is to just brute force it in much the same way that I do in the Janet-based scanner: loop through the things and push things onto vectors in the correct ways.
+This won't be a one-for-one translation, but I suspect it will be easier to manage than banging my head against, especially, the terrible error messages Chumsky's elaborate types give me.
+
+This makes interpolated strings easy enough to work with.
+
+That said, interpolation patterns are harder.
+In particular, I worry whether I'll be able to compile a Chumsky parser with strings that aren't interned/`'static`.
+Because the pattern match will actually have to be a little Chumsky parser guy (doo dah), or some equivalent.
+(In the Janet-based interpreter, I used Janet's built-in PEGs.)
+
+### 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.