From 5a084e8122db328f50f51e9cc022258540c9f30a Mon Sep 17 00:00:00 2001 From: Scott Richmond Date: Thu, 21 Nov 2024 23:52:27 -0500 Subject: [PATCH] write a few thoughts --- thoughts.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/thoughts.md b/thoughts.md index bdf8139..f1feb24 100644 --- a/thoughts.md +++ b/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 -* `tailcall` for tail recursion +* `boxing` for NaN boxing (eventually?) +* ~~`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.