What are we going to implement on top of VML?
We said Scheme (part of R5RS). But how? Incrementally.
First we'll want to implement a proper assembler (text to bytecode), if not already provided by the VM or VM group, probably using variable numbers instead of names. (Perhaps we'll use Emacs lisp to help generate these first programs, so as to avoid having to use a hex editor, and Emacs is part of our existing environment? (If we imagine ourselves implementing some kind of 'Scheme machine' then that would perhaps most likely happen during the early 80ies, and at that time there would be no Python or even Perl to use for the task! Alright, ML appeared in 1973, but doesn't look like as natural a fit than what we have in the editor. BTW Elisp has only introduced lexical scoping recently.))
Then, a lambda syntax, with variable names (but still CPS only, and perhaps with explicit listing of enclosed variables). More or less at the same time, write a minimal S-expression parser, either in bare VML, or using the lambda syntax being developed (fun?).
Then probably a language that supports function returns, i.e. implicit continuations (and a |call/cc| procedure to get to the current one).
Maybe now macros will be implemented.
More syntax, like |let|, |let*|, |letrec|, local |define|.
Now the parser can be rewritten in a more comfortable form.
Perhaps now will be the time to implement integer number support (that wasn't necessary for the above, was it?).
At some point, |set!| needs to be implemented. (Memory objects that allow mutations to do things like |set-car!| will be provided by the VM. (Although that's not strictly necessary?))
Introspection, a debugger, if not already developed organically during the above.
Dynamically scoped variables (make-parameter and parameterize).
Record like structures (although these are not part of R5RS Scheme, some kind of this will be needed earlier already to implement internal data structures; make these (more) user accessible or practical now).
Some kind of module system.
Perhaps an object system. Type declarations and an optional static type system? If we're to extend the workshop, that is--we've already reached the original goals when we get to the previous paragraph. OTOH, part of it may be necessary earlier on for some generic operations provided by R5RS.
Perhaps make S3C available from within Scheme. (As a library, using macros or other kinds of compiler extensions? In fact every new layer above could probably be implemented as such a library, if the proper infrastructure is created early on.)
Possibly implement the full "numeric tower" of Scheme (rationals, floating point, complex), both with syntax and operations (likely using a library for the latter unless someone is particularly interested in implementing that).
Write a pure interpreter (S-expr based) in VML for Scheme first (so we can write the compiler in Scheme soon), or incremental compilation (mostly through macros)?