Plans proposal

[JOT85]

Bytecode

A very very simple, fast to parse bytecode.
It should support all the same directives, so a mk-lang file can be represented perfectly as a bytecode file.

It should have different modes for different use cases.

• Mode 0: Every directive is supported.
• Mode 1: Mode 0, but with code directives (> and >>) disabled.
• Mode 2: Mode 2, but with pattern, rule, include and import directives disabled.

Initial focus

• Go: mk/parser
• Haskell: parser
  • Parsers that can take mklang source files, along with other code files, and parse them in to a representation of the source files (mode 0).
• Go: mk/compiler
• Haskell: compiler
  • Initially, this will take the mode 0 representation given by mk/parser and compile it to either a mode 1 or 2 representation.
• Go: mk/snowball
  • Snowball will be a simple mode 2 bytecode interpreter.

This will allow us to run any mk code - as it can be parsed, compiled to bytecode, then executed (slowly) by snowball.

We should definitely fully develop both the Haskell and Go parsers and compilers separately, as they have fundamentally different approaches and I think it's important to develop them both to see where they lead.

I envision the snowball interpreter to be extremely simple, meaning that perhaps it isn't worth developing 2 interpreters for now, as if they are kept simple, with minimal optimisation, they would probably be almost the same. However if we choose to focus on the interpreter more, we should definitely develop at least 1.

Later on

Later on, we might choose to redevelop both the parser and the compiler - learning from the previous 2. Damn, this sounds a lot like the Starship development... My Go compiler is definitely going to blow up... And you're going to cancel the Haskell one a bit later... But then we can move on to Mk 3 together! YAY!

We will need the compiler to be able to target different architectures.

This could be done in a couple of ways - first, the compiler we already have (/have just redeveloped) could be modified to enable it to compile to multiple targets. Or, we could develop a platform specific compiler which compiles level 2 bytecode (or just a level 2 syntax tree - obviously we wouldn't need to save and then reload level 2 bytecode if the compile was happening in the same program) to the other targets. Level 2 bytecode will be very close to that level anyway, and most changes required will be dependent on the target - such as deciding what goes in which register etc, meaning that it's a sensible place to compile from. If we were to implement it in to the existing compiler, it would probably end up putting it in mode 2 form, then applying more compilation. So perhaps it makes sense to separate the 2 compilers in to different modules.

The compile process could look like this:

Source code -> [Parser] -> Mode 0 representation -> [Compiler] -> Mode 2 representation -> [Target Specific Compiler] -> Target representation

Note that it wouldn't have to be formatted to bytecode and then parsed again in between any of the stages - but it could be if that was desirable.

For example, you could compile the compiler as such:

Language definition -> [Parser] -> Mode 0 representation -> [Compiler] -> Mode 1 bytecode

Source code -> (Mode 1 bytecode from above -> [Parser]) -> Mode 0 representation -> [Compiler] -> Mode 2 representation -> [Target Specific Compiler] -> Target representation

We could then, a lot later on, develop a pattern compiler, which can compile rules to a parser which parses those rules. This would allow:

Language definition -> [Parser] -> Mode 0 representation -> [Compiler] -> Mode 1 bytecode -> [Pattern Compiler] -> Compiled compiler in mode 2 -> [Target Specific Compiler] -> Compiled compiler

Source code -> [Compiled compiler from above] -> Mode 2 representation -> [Target Specific Compiler] -> Target representation