From 2a83dbb96c0d54c567ab179245b00eacd48717ea Mon Sep 17 00:00:00 2001 From: Scott Richmond Date: Fri, 22 Nov 2024 00:07:52 -0500 Subject: [PATCH] moar thoughts --- thoughts.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/thoughts.md b/thoughts.md index f1feb24..01c4dca 100644 --- a/thoughts.md +++ b/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.)