Quick
index
main
eev
maths
blogme
dednat4
littlelangs
PURO
(GAC2,
λ, etc)
(Chapa 1)

emacs
lua
(la)tex
fvwm
tcl
forth
icon
debian
irc
contact

Little Languages

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 too small.

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).

BlogMe3 (2007)

  • A complete rewrite of BlogMe2 - faster, cleaner, etc, etc.
  • 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.
  • Documentation:
    • 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...

BlogMe2 (2005)

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.

Dednat4 (2002-2003)

  • 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 sublanguages.
  • An html version of the article.

Flua (2000)

TH - a Tcl-based language for generating HTML (1999)

diaglib.014 (1998-1999)

  • 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 these nodes.
  • 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