Firth is of Forth
The past few weeks I've been spending about an hour a night playing with Firth again. This is probably one of my longest running projects which seems perpetually in a concept phase. It has been underdevelopment in one guise or another since roughly 1994, when I had the original idea, known as Glish. Firth was a revisiting of Glish that happened at round 2003, where in I started playing around with some ML inspired concepts, but it is increasingly clear that ML w/o type systems is like Forth w/o stacks, and so it is trending back to Glish, without the TCLish feeling.
At its heart Firth is a minimalistic object oriented forth with concurrency. Each object gets:
- it's own lexicon of behaviors (a forth dictionary)
- it's own data and return stack
- it's own process
- it's own inbox
Each object is a little VM that can operate within its own context, that compiles just enough code to do what it needs. Flow control takes the form of message passing between objects. When an object passes a message to another object it also transfers control of the CPU. This approach works because the context switch is no more expensive than a C function call. The call mechanism passes the top of the data stack of one object to another, and returns a value on the top of the stack. This means that most operations are shallow, and stack juggling is often avoided entirely.
The past two nights, I've been playing around with ANSI control codes. Part of building Firth is building a screen editor for programming. Rather than rely upon a traditional ASCII text + files approach, I am leaning towards a more modern image based approach with structured source objects and a built in webservers for sharing. There is really no good reason to stick with text files. You can't easily share state, requires translating between binary representations, and isn't human editable without losing information. Using source control preserves snapshots, but does not allow for the sort of branch / edit / compile / run with undo that I'm looking for.