Sunday, May 1, 2011

M0ving Forward

dukeleto and I shared a hotel room at LinuxFestNorthwest and had a great opportunity to talk about M0 after our respective talks.  We went over the state of the spec and what the best forward might be.  We also tried to look at what the future M0-based Parrot workflow will look like and how we can get there, though we got distracted before the crystal ball was delivered.

First, dukeleto mentioned that M0 is less discoverable than it needs to be, especially for a project that we expect to become Parrot's new foundation.  He suggested that we write a document that someone can read to get a clear 10,000 foot view of M0 and how its pieces fit together, a glossy brochure of sorts.  This could be either an introductory section in the M0 spec or a separate document.  The important thing is to have something we can point people at so that dukeleto and I aren't the only ones who can readily articulate what M0 is and where M0 is headed.

We also made some updates to the spec to make getting values from the variables table less confusing.  This is fairly minor in the scheme of things, but so is Perl's "say".

Last of all, we hammered out a plan for how get a working M0 prototype assembler and interpreter.

atrodo has been very valuable in providing his prototype Lorito implementation, both in his documentation and in the way he's had to bring assumptions to the surface to get a runnable interpreter.  His implementation differs from the spec in a number of ways (many of which are because it predates the spec), but it's been helpful in those places because it shows us what we want by counterexample.  The next (brief) stage was a set of prototype PIR dynops of M0 I hacked together.  This was great to get some runnable code that was close to the spec, but it very quickly ran into the impedance mismatch between the high level of PIR and the low level of M0.  The effort on the m0 prototype dynops wasn't wasted, but they've reached the limit of their usefulness.

The next step we've decided to take is to implement a separate prototype M0 assembler and interpreter.  dukeleto is be working on the assembler and I'll do the interpreter, both based on the M0 spec in the m0-spec branch on GitHub.  The only interface between the two will be M0's binary representation, so we can easily change one without needing to modify the other.  We're trying to converge on the structure of both the interpreter and assembler, but we expect this to the last prototype rather than a final implementation.   We'll also be writing tests against both the interpreter and assembler which we can later use against any future implementations.

dukeleto has started hacking in the m0-prototype branch in src/m0 and managed to get some very basic tests passing before he went to sleep.  We'll both be using Perl 5.10 as an expedient, since we don't expect these projects to serve as more than prototypes.  As a temporary measure one of us will need to hand-generate a couple simple bytecode files to verify that the assembler is working correctly.  These files will live in t/m0 in the branch.  The test code will be a minimal hello world program and a slightly more complex multi-chunk M0 program to help iron out inter-chunk interaction.  We haven't decided on what the complex example will be yet.  This is a part of the spec we'll need to work on as we come to understand what implementation makes the most sense.

Overall, rooming together at LinuxFestNorthwest has been very helpful in moving M0 forward.  Both of us have used the opportunity to bounce ideas off each other and to get the M0 train out of the station.  We're still a couple stages (and probably one more face-to-face meeting with allison and/or chromatic) away from a final implementation, but we can see the light at the end of the igloo, and it's looking pretty good.

There are a couple things that still need to get done.  In the interest of trying to keep them from getting dropped on the floor, they are:

  • Map out what a future m0 workflow will look like, what we need to do now to make it possible.
  • Make M0's roadmap and status more discoverable by making a glossy brochure that will communicate the idea effectively to someone who hasn't heard of M0 before.

No comments:

Post a Comment

Post a Comment