• flutter: This is Henk’s baby, not mine.

  • autometa: some playing around with types, written in ocaml. It does typechecking for procedural types. I’m not sure if anything useful runs.

  • icode: bytegen — some code in Scheme that translates s-expression syntax to calls to the bytecode generator.

    • a double-priority parser, in ocaml

    • another in scheme

    • a bytecode generator and interpreter, in C

    • typetool, in ocaml.. Is this the same as in autometa?

    • wordreader.scm - similar to another one.

  • intel: an intel code generator. Stores assembler code directly into memory.

  • intoo: another intel code generator? What is this? These two code generators seem to share a lot of code. Accidentally different development branches, maybe?

  • pol: Speculation on bootstrapping a fully typed system.

  • trage2: Another bootstrap attempt, based on Scheme. Not clear what thie code does, though.

  • And elsewhere, there’s a typed threaded code interpreter written in Modula 3.

  • Also elsewhere, there’s rdp, a parser/transformer that translates its own code into C. TODO: Examone rdp to identify primitive operations for a parser.

TODO:

Make these a bit more compatible.

Find out what language(s) these tools accept. They are probably different. Do they need to be?

See if any of these could eventually work together.

It may be useful to make a high-level intermediate-code emmitter for Algol 68, just to see what such a thing would look like for a complete language. Presumably it would have Algol 68 operations, including all coercions. It would be interesting to see the mode table and the bindings between declaration, definition, and use.

TOFIND:

  • Wasn’t there a stack-machine interpreter somewhere written in Modula 3? Yes, there was, in ~/farhome/hendrik/dv/pq. Was it the most advanced one I wrote? Would it be better coded in OCaml? OR Scheme? Or not? I recall it had a bit of code in the direction of dependent types, but didn’t truly have any of those types. Maybe I should really start with that. Make it generate stack-machind output like that accepted by the other tools.

  • rdp: This is a parser, tree-transformer, and code emitter written entirely in itself in 8 or 9 bootstrapping stages. It might be a usefull tool. It does no typechecking, but that’s unlikely to happen until we have an effective error message system that’s independent of the success/fail mechanism — or at least is a supplement to it. Attempts to add typechecking so far have been a miserable failure.

Ah yes. These will probably be sitting on farhome. Along with the intel assembler threaded code interpreter and its 64-but equivalent interpreter. And the garbage collector that collects itself written in the threaded code. And its rudimentary type-checker.

Could use OCaml or Scheme to generate code for either of these to read.

2014 07 05:

What’s worth keeping about these things are their specifications. Or rather, taking them and elaborating on them and making them consistent. So the next main project will be these specifications.

What are these interface layers?

There’s the type-checked abstract machine in the Modula 3 code.

There’s the nontype-checked abstract machine in C and assembler code, and the type-checking imposed on it by the input protocols, which gradually became an execrescence.

There’s a byte-coded abstract machinelet in C and its code generator in Scheme.