Language Design Overview

This page basically gives a historical overview of all the programming languages I have designed (and sometimes implemented) over the years. Some of them, notably E, False, Bla, Aardappel, SHEEP and Lobster have their own pages.

  • Lobster (2011-2013) A game programming language with pythonesque syntax, very terse blocks/anonymous functions, multimethods and lots of other neat features, see here

  • Restructor (oct 2004-2010) A tree based graphical programming language/environment whose primary aim is to do away with explicit abstractions completely. The environment allows programming by cut&paste, keeping code factored automatically, with no need to create “functions” explicitly. Two prototype implementations. Paper “Abstraction Considered Harmful” forthcoming.. :)

  • TreeSheets (2008) The hierarchical spreadsheet TreeSheets contains a visual programming language that computes using operations contained in cells (as oppposed to “behind” cells as in traditional spreadsheets) both left to right and top to bottom, somewhat similar to APL. Example.

  • Boar (2006) A visual language akin to FP with a zooming interface based on the OverView code (see OverView for an early screenshot).

  • Bear (aug 2005) More complete language design that integrates a few recently researched features, but its main focus is on a very clean and seamless unified macro/function/class/coroutine system for the ultimate in (re)factoring power, and also uses the ownership reference counting model below, etc. In general, this is a less adventurous design, more targeted towards being able to build an implementation that is practical and very fast.

  • Toad (july 2005) A string based language whose sole purpose is to be able to be implemented in as few lines of code as possible, while still being a “complete” programming language usable by average programmers. Goal to be used as a tiny plug in language for simple scripting/configuration.

  • (staged_computation) (may 2005) an attempt to elegantly move from the two stage compile-time and run-time to N stage model, by adding any number of stages in both directions.

  • Horse (apr 2005) generalizes the concept of a spreadsheet to arbitrary tree structured data, but keeps the grid based view. Also allows more complicated computations/functions to be specified using the existing visual representation, making it into a beginner friendly graphical programming language.

  • (ownership_reference_counting) (june 2004) combines linearity and reference counting for cycle-problem free very fast automatic memory management

  • (flat_file_memory_management) (june 2004) Stores all memory used by a program (a tree) as a flat, “inline” structure with no pointers (!), just offsets. Uses the MMU to reallocate virtual memory to make inserts/deletes of tree nodes bearably efficient. Has as big attraction that it makes memory management trivial, and very space economic (in most cases 16bit offsets can be used instead of 64bit pointers, this can be decided on a per-page basis).

  • Frog (dec 2003) Another attempt at using a stack language for graphical programming, much like growing_example_stacks below. This time tries to reduce the need for mentally picturing the stack by always showing the state of the stack inline with the code from the perspective of the instruction currently being edited/executed.

  • CryScript (aka DOG) (nov 2002) Scripting / Game programming language I created for Crytek’s next gen engine effort. Tries to balance the friendlyness and conciseness of scripting languages with Java/C# level base language for larger scale game programming. Strongly typed but can be used mostly without type annotations, JavaScript style syntax, very convenient built-in vector and map types, classes, interfaces, exceptions, region based memory management, dynamic module loading & linking, automatically generated C++ native interfaces, compiler with strong optimizer & analysis component, very fast register based interpreter. Beats well known other scripting languages by large margins. Mature implementation (not available, this is up to Crytek).

  • Wortel (sept 2002) Unifies coroutines, functions and classes into a single small construct.

  • NVNSRRML (feb 2002) “Non Verbose Non Semantically Redundant Readable Markup Language”, i.e. the antithesis to XML. Also featuring ENVNSRRML (Executable NVNSRRML), a macro / document processing / transformation / programming language.

  • MOLE (dec 2001) MOLE is a family of languages rather than a single one, each one implements linearity as part of an imperative language using different constructs and different levels of intrusiveness. Think STL auto_ptr as part of the language & type system with Call by Name, using analysis to reduce the burden on the programmer. Besides linearity, MOLE features a smalltalk-y syntax, hygienic macros, graph types, and minimalistic coroutines.

  • COW (june 2001) COW is another “environment” language like Bla, but is much more radical in unifying all possible programming language constructs into one (the environment). Extremely tiny language definition covers classes, objects, modules, functions/methods function-environments, scopes, (recursive) lambda’s, tuples, lists, arrays, monitors, futures, bags etc. etc.

  • linear_lazyness An investigation into the interactions between linearity and lazyness, and possible optimisations.

  • PIG (oct 2000) PIG is an “anti-functional programming language”, an experiment to see how far one can get in a language which only has global state (in the form of stacks) and argument-less functions. Inspired by OpenGL and the “move” cpu.

  • feedback_trigger_VPL A graphical programming language based on (cyclic) dataflow, which embeds state into the dataflow, making for natural definition of “objects”, better code sharing, clearer dependencies, good seperation of core & peripheral methods, and reduced dataflow connections. Easy “environments” and lambda objects. See a mockup for a stack ADT here.

  • Goat (april 2000) Specialised language that can specify binary (file) formats & possibly transformations on them, from which a variety of translators, converters, browsers, editors etc. can be automatically generated.

  • SHEEP (feb 2000) New scripting/querying/ipc/programming language I’m doing for Amiga Inc., with as basis a not as hardcore version of Sheep. Expect familiar beginner friendly syntax and semantics coupled with multimethods, automatic memory management without garbage collection (linearity), powerful datatypes, pattern matching, strong and dynamic typing living together in harmony, integrated access to all the new Amiga OS features, and optional compiled output comparable to C in speed and size. More here.

  • Sheep “hardcore” version A fully linear (one reference) referentially transparent strict functional language with inclusion polymorphism and easy usage of state & OS. Designed to be implemented to allow for an extremely high level of optimisation (no garbage collection, no aliasing, only in-place update, specialized dispatch).

  • WadC (dec 99) A cross between a very minimal lazy functional programming language and a macro preprocessor. Used as the language to program 2d line structures with intended as maps for the game Doom. (more here)

  • UhOh (oct 99) A cross between Monads, Backus’ FFP, and my Ni! and Kartoffel languages. Uses a friendly version of Monads layered into FFP’s higher order functions to allow for easy (compositional) state, io, exceptions etc., in a referentially transparent language.

  • Aardappel (optimized) (jul 99) Simplified the original language greatly by removing function values (these can be expressed in the language itself using specificity ordering). (details here)

  • DaMaul (sept 98) A very minimalistic “chemical reaction” type language in the same family as Linda & Gamma. The only language construct left is the “communication” which react in pairs.

  • Boerenkool (oct 97) Another design for a graphical programming language, this time based on tree structures with clever tricks for sharing, and programming by example. Has now been integrated as the syntax part of Aardappel, but idea can be applied to a whole class of (funtional style) languages. Here is the full picture

  • Aardappel (nov 96) (previously known as “Hekking” and “Sauerkraut III”). Does the obvious thing and combines the ideas present in Sauerkraut I, II, Schnitzel and SchnitSauer to come up with a “Concurrent Tree Space Transformation Language”. Does visual tree rewriting with Linda type concurrency, transformations (i.e. linearness + object identity) and other neat things. Design has been polished a lot during ‘97. (see its own homepage)

  • [alt_pattern_match] Shows a syntax to have left and righthandsides of rewriting as one huge expression, and some various weird ideas.

  • Sauerkraut II (nov 96) Extends Sauerkraut with dynamic contexts to match onto.

  • Schnitsauer (oct 96) Attempted to combine dataflow and Linda into a general visual concurrent component type language. made to be very compositional and flexible, inspired on Schitzel.

  • principles, bags Sums up some of my general language design principles, and explains why the various languages below based on Schnitzel and Sauerkraut are so great. Deals with “Reducing the Complexity of Dependancies”.

  • BRAAF Computing with single-value objects that trigger bits of code upon reading/writing.

  • (fundamental_reuse) On how reuse works and why the traditional ways of doing so (including OO) don’t work.

  • Schnitzel (jan 96) An even simpler design for visual programming based on Linda tuple-spaces. looks even less like programming.

  • Sauerkraut (dec 95) A completely different attempt at a VPL: using term-rewriting and bags, and a new evaluation scheme. (related to GRRR, GRR, UHH, UH)

  • Kartoffel (nov 95) Uses a system of higher order functions similar to Backus’ FFP language to create a visual language. layout is purely composition of boxes into bigger boxes. “Kartoffel” is the ascii version.

  • (no_methods_oo) (jun 95) An OO language that uses just reading/writing/creation/deletion as messages to an object.

  • GRMPF A purely functional language with novel syntactical constructions to make programming more practical in context of ADTs etc.

  • Apfelstrudel Unites all previous VPL layout methods into one semantical framework with possibly different representations.

  • (inheritance_harmful) Functional alternative to OO: uses compositions of terms and delegation relations between them, and transformations instead of patternmatches. (related to Ni!)

  Point = Loc:Col(c) {
    Inverse Point(c=C)  Point(c=256-C)
  • (growing_example_stacks) Trying to reduce the visual complexity of VPLs: using stacks with example values in them.

  • UHH (mar 95) Programming by example using bags.

  • UH (feb 95) 1st class concurrent bags. Linda meets Actors meets BRAAK.

    c c eat:P     => ok->P.
    numphil:X>0   => numphil:X-1 c room:*->{
                          hungry `room:R  => eat:*->R.
                          ok `room:R      => c->R c->R hungry.
  • Ni! (feb 95) Study on polymorhism, and how a system based interfaces and certain compatabilities between them should be more powerful and compositional than OO.

  • GRR (jan 95) Term rewriting language meant as language implementation tool, featuring higher order patternmatching that can be used both as grammar (parse+lex) and transformation/generation. (related to GRRR). (see an example).

  • Bla (end 94, unix/amiga/…) An unpure functional/OO language, strong typing + TI (makes the ideas already present in Blerk into a solid and usable design). Implemented in C++ as a compiler to portable bytecode (the Emmer intermediate language) which could then be interpreted etc. After the initial paper end `94, Bla was fully developed and changed quite a bit during almost all of ‘95. Have a look at the Bla homepage .

  • X780040 (end 94) General low-level virtual machine design, meant to support both Bla and Plop, and anything else.

  • G (aug 94, amiga) Graphical dataflow language. details various forms of efficient non-concurrent evaluation, and various DAG layout algorithms, possible type-systems etc. Also ascii syntax design without identifiers, and how to how to enhance compositionaly and reduce dependancies between software components (not overly succesful). OO variants considered. A prototype implementation (a dataflow editor) was started.

  • (lazy_generators) (jun 94) Reinventing the wheel: the deforestation optimisation for lazy FLs. uses composable generators ipv interim lists.

  • GRRR Actually various designs in one, all based on term/tree-rewriting / equational logic. meant also as compiler toolkit. many evaluation strategies considered.

  _:E' = S:E
  _:E' = stats(R):E'
  stats(S:R):E = []:E''
  • BRAAK Forth meets Prolog: stack language that uses unification to retrieve values from stack instead of push/pop, or Ordered Unification Spaces.
  append:[ O L L <=> nil O ]
  append:[ O H:T T O append X H:X ]
  • OOHNO! (jan 94) Fundamentalistic dynamic delegation OO language. very primitive, small language core. very “Self”-like.
  stackt <- push (method# <- new);
  (stackt push) :: [
    elements write top new;
    top += 1;
  • Blerk (nov 93) the very basic semantical foundations of Bla (1st class environments as objects/functions) all present already here. rest of the language (syntax + semantics) very primitive.
  stack {
    private top = 0, data:list;
    pop { [ data.get(--top) ] };
    push { public val [ data.put(val,top++) ] };

Blerk was supposed to have user definable syntax. All language constructs would have the same term(a,b) syntax, and on the fly macro/grammar-rules added any possible syntax to the language. Normal keyworded syntaxes considered as well.

  • False (march..may 93, amiga/unix) A very cryptic but very pure Forth type language with anonymous function blocks. Implemented as compiler (<1024 bytes 68000 exe) and a portable interpreter in C. Was moderately succesful. See the False homepage.
  [$1=$[%1]?~[$1-f;!*]?]f:          { fac() in false }
  • Aaargh! (93) A complete E redesign. more orthogonal, more functional, different syntax, full pattern matching, lists/gc/TI etc.
  map f [] = []
      f [head|tail] = [f head|map f tail]
  • NGRC (jan 93, amiga) A special grammar formalism with features for generation & randomness (music oriented), implemented in E as a compiler to protracker modules.
  mynote -> { 10 [D,2] | 1 [D#,2] | 1 [Db,2] };
  • Yax (end 92, amiga) A procedural beginners language with lisp-like syntax. Implemented in E as interpreter, uses same lex-pass techniques as E compiler. Just had one very fanatic user (Ben :)
  (defun fac (n) (if (eq n 1) 1 (* (fac (sub n 1)) n)))
  • PLX (may 92, msdos) A procedural language with lisp & logic features and uniform square bracket syntax. Implemented as interpreter (in quickbasic, slow), again very unconventional parsing, lists stored as strings.
  • E (end 91..97.., amiga) Started out as enhanced Dex, ends as C++/Ada type language with functional features. Implemented in pure 68000 assembly (extremely fast) as a one-pass compiler (plus one lex-only pass), again uses job-code language for code-generation. Generates 68000 executables straight away. Has been and still is a huge success: have a look at E homepage.

  • Dex (90 / 91, amiga) A non-recursive pascal/C mixture, precursor to E. Implemented by a two-pass compiler (in gfa-basic, very slow), used extremely ad-hoc parsing techniques. Generated quite fast 68000 assembly source (a68k & blink used as backend). Got an article in the german “AmigaPlus” magazine. See a sample session with the compiler compiling HelloWorld:

  PROC main()
    WRITE 'Hello, World!\n'
  • MPL (1987, C16) My first ever compiler (on the Commodore 16) implemented a tiny low level language (a mix between asm & basic) and compiled to fast executable 6502 code. The compiler itself (written in basic, terribly slow) was two-pass, and used a strange job-code language for code-generation.

If you look through the list, you’ll notice that many design relate to each other and that there are many reoccurring themes. In this respect, the Aardappel/Boerenkool designs finally put together something that was latent in many previous designs.

Implementation wise, besides the implementations mentioned in this text I have made loads of implementations for existing languages, in particular all sorts of Lisp, ProLog, Lambda Calculus and Tree Rewriting variants.

Here’s my programming languages bib file.