Dived into tcl wiki after writing a program with tkinter (tk python bindings), it's amazing to see a community speak about other paradigms. Reading how they approached FP idioms for instance. I felt this way with perl too. These are two old languages that are mostly ignored nowadays (except for the perl6 has shipped) but they have very interesting ways.
It's a tiny Tcl subset, implemented in only a few kloc. It's used by Fossil as a HTML templating engine but it's easily adaptable for other things. It's small enough to be understood and does an excellent job of demonstrating the core principles of how string-processing languages think.
@david-given probably knows this, but that TH1 is Tcl-ish is no surprise, given fossils founder/principle author is drh (Richard Hipp).
drh is a former Tcl Core Team member[0], and probably most famous as the author of Sqlite, originally a Tcl extension that "escaped into the wild"[1]. Sqlite also has a comprehensive test-suite written in Tcl[2].
I was (pleasantly) surprised to find out Fossil used a Tcl-like language for templating.
Tiny Tcl implementations are fun in general and perhaps easier to produce than tiny Scheme implementations — as long as you are willing to concede that everything really is a string. :-) (I.e., no caching binary representations; you have to parse from scratch each time.) In a similar vein as TH1 but with a little more functionality there are Picol (https://tcl.wiki/Picol) and LIL (http://runtimeterror.com/tech/lil/).
Disclosure: I maintain an expanded fork of Picol. The original version of it written by antirez was only ~550 LOC but with suchenwi's additions and mine it is now around 3100. There is a link to it on the wiki page. The change that I am most fond of is making it an stb-style (https://github.com/nothings/stb/) header library.
You don't have to treat everything as a string. I've written a Tcl interpreter in VHDL and it avoids the traditional pre 8.0 string interpretation. It parses everything into an AST and interprets that instead. This saves on the overhead of string processing mostly static code inside another interpreter that isn't optimal for such tasks.
Oh, I agree with you on that. My point was that Tcl makes it especially easy to "cheat" and avoid building an AST. You may do this when you only care about writing an interpreter in few LOC, like the original version of Picol, quickly.
A Tcl interpreter in VHDL sounds interesting. Do you have a public
repository for it?
TH1 (literally "Test Harness #1") was originally conceived as a minimalist reimplementation of TCL sufficient to run the TCL-based SQLite test suite on SymbianOS. That use case never materialized. But later, when I needed a small and lightweight scripting language for Fossil, TH1 was drafted for that alternative purpose.
