NB I didn't fully read the readme or your article carefully so might be under some false impressions, but I'll post this anyhow.
Seeing how low-level your source code is, would your "compiler" perhaps not be better thought of as an assembler? So if your interpreter is a VM for this assembly language, then like WASM, you should be able compile a high level language into mnm. Obviously a LLVM backend is in order so I can compile my own apps into images of M&Ms! (request #1)
However there's a missing piece to this analogy. If ASCII mnm is the assembly language and you have an interpreter for that, then my analogy fails. After all it isn't an assembler to a machine code / byte code of an mnm VM. But what if it was? I think you should treat your current stack as phase 1 and (request #2)
next work on remixing your compiler (assembler) and interpreter into the mnm VM to complete the analogy. And what form should your VM's machine code take?
Images of M&Ms should be your machine code.
Most of the time a machine language for a processor / VM is the representation that's most efficient for execution, and a corresponding interpreter of its assembly language is comparatively slow. But where's the fun in that? Looking instead from the perspective of coding difficulty, arranging M&Ms into rows and taking a suitable photo, perhaps a panorama, is comparatively more challenging than writing an ASCII text file and seems equivalent to writing machine code directly, in the style of our founders from the 1950s (and Nasir Gebelli).
So the mnm VM would need your compiler's feature for parsing images (by the way do you call it OCR, optical candy recognition?), but instead parse them directly into AST. Making ASCII mnm assembly be an IR of your VM would be exactly your existing compiler + interpreter stack and would ruin everything.
Just an idea.
NB I didn't fully read the readme or your article carefully so might be under some false impressions, but I'll post this anyhow.
Seeing how low-level your source code is, would your "compiler" perhaps not be better thought of as an assembler? So if your interpreter is a VM for this assembly language, then like WASM, you should be able compile a high level language into mnm. Obviously a LLVM backend is in order so I can compile my own apps into images of M&Ms! (request #1)
However there's a missing piece to this analogy. If ASCII mnm is the assembly language and you have an interpreter for that, then my analogy fails. After all it isn't an assembler to a machine code / byte code of an mnm VM. But what if it was? I think you should treat your current stack as phase 1 and (request #2)
next work on remixing your compiler (assembler) and interpreter into the mnm VM to complete the analogy. And what form should your VM's machine code take?
Images of M&Ms should be your machine code.
Most of the time a machine language for a processor / VM is the representation that's most efficient for execution, and a corresponding interpreter of its assembly language is comparatively slow. But where's the fun in that? Looking instead from the perspective of coding difficulty, arranging M&Ms into rows and taking a suitable photo, perhaps a panorama, is comparatively more challenging than writing an ASCII text file and seems equivalent to writing machine code directly, in the style of our founders from the 1950s (and Nasir Gebelli).
So the mnm VM would need your compiler's feature for parsing images (by the way do you call it OCR, optical candy recognition?), but instead parse them directly into AST. Making ASCII mnm assembly be an IR of your VM would be exactly your existing compiler + interpreter stack and would ruin everything.
Just an idea.