I've been creating "little languages" since always - that is, since
I realized that I wasn't able to program what I wanted using only
existing languages, because the programs get too big and my brain is
Before 1995 I used Forth a lot (Forth is both a
little language and a meta-little language) without attempting to
modify it in any radical way. My page about Forth is elsewhere.
An entry about little languages at the C2
wiki (Bentley's article).
BlogMe4 (2011): here (functional, but undocumented).
Dednat5 (2011): here (functional, but undocumented).
- A complete rewrite of BlogMe2 - faster, cleaner,
- Its source code:
- The core:
- Words to produce HTML from .blogme files:
- charset.lua - deal with non-ascii characters.
- anggdefs.lua - the BlogMe words that I use for the pages at angg.twu.net.
- Functions to produce HTML from ascii files (e-scripts):
- Functions to produce makefiles:
- The top level:
- blogme3.lua - the top level: load libraries, process command-line options.
- It still needs some functions from my $LUA_INIT file.
- Most of the ideas in this text about blogme2
still hold, and there's a comparison between BlogMe3 and Forth,
Lisp, and Tcl here - but everything is
incomplete, this is a work in progress...
The Digit Machine (2004; not implemented)
- Would have a memory of 10000 "digits" (cells holding a value from
0 to 9).
- The contens of the memory could be displayed (graphically, on X)
as a grid of 100x100 colored digits. But I didn't know how to
program that. (Updates, 2006: the IMSAI had this kind of
memory-mapping; Icon's graphics for X are
pixel-oriented instead of entity-orientend.)
- Bytecode interpreter ("digitcode interpreter"?) inspired by Crim.
- It would have no registers - the last 4 positions of the memory
would work as SP, and IP would be *SP.
- Mainly for didactical purposes - for explaining how the state of
the machine changes at each step, etc.
- Here; includes a version of miniforth.
Bootstrapping Forth in 50 lines of Lua code (2001)
- A few notes for a technical report that I
planned to write.
- Its main directory: miniforth/
- The part that generates bytecodes for an inner interpreter
written in C: miniforth/crim/
- News (2007): I rewrote miniforth from scratch; the old version is
ugly, the new version (miniforth3) is cute. Also,
I'm writing an article about it for the Lua Gems book, and I'm rewriting BlogMe on top of miniforth; see this for some docs on the new version. The
new BlogMe will use Lpeg for some of its
- An html version of the article.
- See the diaglib section in my Tcl page.
- The library: diaglib.014
- Source code for some diagrams: desenhos.014
- Written in Tcl/Tk (my first serious program in Tcl/Tk, btw).
- It was a little language for specifying nodes - containing text -
and arrows - that could be drawn in several styles - connecting
- It was possible to drag some of the nodes with the mouse; the
arrows would be redrawn to adjust to the new positions. Also, the
positions of some nodes could be derived from positions of other
nodes - we could draw a square with corners A, B, C, D in which A,
B and C could always be dragged and D would be adjusted
automatically to make the figure a parallelogram.
- I used diagrams made with it in my MsC thesis - the trick was
that Tk could take what was drawn in a "canvas" and convert that
to Encapsulated PostScript.
Crim: an alternative inner interpreter for Forth. (1995-)
- My page on that.
- Proof-of-concept implementations:
- crim/ - the older one, written in C and PForth.
- CRIM1/ - another implementation, in C, Tcl and Nasm.
- Its features:
- very compact bytecode
- extensible - new modes besides "Forth" and "Head" could be added
- easier to explain than the usual inner interpreter
- called functions in other languages (e.g. C)
- easy to implement "words with immediate arguments" like <."> in it
- Ideas for which only very primitive prototypes exists:
- 2D animation of backtracking and parsing
- Ideas that never had running prototypes:
- dictionaries and an outer interpreter
- complex bytecode modes besides "Forth" and "Head" implemented in
Crim itself - i.e., implemented in "Crim bytecode programs" instead
of hardcoded inside the inner interpreter
- Crim in Crim: an application of the above idea
- A debugger for Crim
- A MachineForth inner interpreter written in Crim