I claimed yesterday that the OPy solution is more general, less work, and may benefit end users. Why?
The previous plans aimed to avoid rewriting the OSH parser, but OPy should be able to run all of OSH, including the runtime. If speed becomes an issue, I can either write native extensions or compile OSH to the OPy VM, removing the double interpretation.
OVM will initially be a Python 2.7 VM, but it will also evolve. I've carefully accounted for the total code size because I want to be able to make aggressive global changes to the language and VM.
For example, I ripped out the middle of OSH and replaced it with [ASDL], to the great benefit, and I expect to do similar things iwth OPy.
I still have to implement the Oil language, and I want to write it in OPy rather than native code. Remember, Oil is a bigger language than OSH, because it includes the functionality of shell, awk, and make.
One reason is that I'm taking advantage of work done by others. The beauty of open source.
I mentioned bootstrapping Oil — writing Oil in Oil — in a few posts, but not gone into detail:
In retrospect, this plan doesn't make sense. Because oil doesn't exist yet, bootstrapping Oil is writing two complete interpreters away! That is, I would have to write Oil in another language before I can write it itself.
It makes much more sense to write Oil in a bootstrapped language: Python, which will be evolved into OPy.
An obvious feature would be to expose Python/OPy to end users. Just as you can write Python to customize Vim, you may want to write Python to customize your shell.
It's a much nicer language than shell. In my experience, writing custom completion hooks in bash is a nightmare.
But this plan is hazy, because I had hoped this role would be filled by Oil. Oil could not only be a better shell language, but an extension language for OSH.
There is much more to write about:
I need to write more code before addressing these topics, but [leave a comment][comments-url] if you have questions. Is this crazy?