Crafting Interpreters has two chapters on classes. I've gotten through the second chapter. Test coverage is still not great, only 85%.
I forget when I planned to take a break. Maybe it would help to lay out the changes I want to make:
- 100% test coverage
- Good mutation coverage
- Various ergonomics improvements:
- Convert tokens to enum.IntFlag, then convert the helper functions that process them to use bitwise operators instead of sometimes sets, sometimes not.
- Convert the Visitor protocol to a fluent interface
- Generally convert tuple returns to fluent returns or iterators
- Audit some of my weirder divergences from JLox, such as various one-off methods
- Reorganize the modules to make importing less fraught
- Implement garbage collection for the arenas. ("Wait, you wrote this in Python and it doesn't have garbage collection?" I wrote it using immutable data structures, because once you have those worked out, it's much easier to reason about the code. As a side effect, every value in the interpreter lives until it gets overwritten, and there's no such thing as a delete.)
I don't think there's any urgent need for me to either work on this, or deliberately not work on it, so I'll see what I feel like doing tomorrow, but I should probably try focusing on other things first.
One thing that it would be nice to have before the mutation testing is a version of my limit-coverage tool that works with the whole "monorepo" layout that I seem to be going with for a bunch of projects now.
(... "I have several mono[repo]s.")
Riffs aside, that would be nice because one of the things that made mutation testing against Structured Data bearable was that each module had an associated test module, so when there was a mutation, that meant that I could declare that catching the mutation with a non-associated test module didn't "count", and therefore skip running all of them.
Maybe I should do the "module reorganization" step before "mutation testing". Anyway, that's a question for another day.