> "match (xs head)" is not described anywhere (on the page at all). “A ‘match’ expression takes an instance of an ADT, matches on its tag, and unpacks its fiel

> "match (xs head)" is not described anywhere (on the page at all). “A ‘match’ expression takes an instance of an ADT, matches on its tag, and unpacks its fields (if any) onto the stack so they can be manipulated.” (Under the “Algebraic Data Types” section.) By a “traditional” tokenizer I mean “a tokenizer more like what you’d expect from a mainstream C-like programming language, not just splitting on whitespace like Forth does”. It has some superficial similarities to Forth (postfix by default), but overall has more in common with the ML and C families (Haskell, OCaml, Rust, C, C++). The reason I decided to start labeling it a “systems” language recently is to get the attention of the people from C++ and Rust who I’d like to try it out eventually. The implementation isn’t nearly close to this, but the language itself is designed to be easy to implement efficiently (strict evaluation, guaranteed tail call elimination, unboxed data types, no GC or nontrivial runtime required) and has a lot of static structure available for the compiler to do optimisations (static type and effect system). Kitten’s docs are perpetually in an awkward state because I’m the only one working on it regularly—they’re usually slightly behind the compiler version I’m actually working on, and occasionally describe language features that aren’t yet implementation features (i.e., they should work but are known to be buggy/incomplete in the current version). I’m focusing on the next major round of changes to the compiler, which I hope is the last before a release, and I plan to go through all the docs and flesh them out as part of the eventual release process.