Dan --
Thanks for mentioning Jako. It usually gets no respect. :)
But, I think Jako is "working" for some definition of "working". But, it is clearly not an idiomatic compiler in that its using old conventions (not surprising, given its history).
Did I miss the creation of the compiler-writer list? I need to figure out what needs to be done to convert Jako to a compiler worthy of regular mention, and I suspect the perception problem it has is due to its ageing world-view on how to compile a language down to IMC. Last time I wrote code for it, there were impedence mismatches between IMC and the natural way of thinking about Jako code. Maybe those are gone now, but I could sure use some guidance getting up to speed on The Right Ways as they currently are.
Or, should I wait until some of the changes you contemplate in this message so I don't have to change calling convention stuff *again*?
Regards,
-- Gregor
Dan Sugalski wrote:
In what's seems a rather bizarre twist, Parrot's getting production ready. Yes, I find this really strange, and no, I'm not even talking about my work project, though I probably should. Python and PHP are both near-beta ready, and Span looks... well, it looks damn nice.
As such, I think we're in a state where the things that have been in and implemented should be documented and fixed, and the things that are in flux should un-flux and get fixed. I'm tired of most of languages/ being broken as well -- I'd like to get forth, BASIC, Jako, Cola, and the rest all working again, and like to not break m4.
So, here's what we're going to do.
First, I'm digging into Leo's proposal for changing sub calls. It has user-visible issues in that when we're done hashing it out, it'll mean no need to do save/restores.
Next we're going to put the return continuation, sub PMC, and object PMC into the interpreter structure. They can stay in the registers they're in now, I expect. That'd be convenient, and we're not really short of registers.
Then we kick the python bytecode compiler around until it works. This will, I expect, involve finalizing exceptions, so we will.
When we're done with that we're going to release 0.2.0.
After that we're going to revisit, and then lock down, the embedding and extending APIs. When we're done with those, we're *done*. We'll put together source tests, which'll remain canonical unless the tests themselves have bugs.
Then we release 0.2.1.
After that I think we address the string internal issues, and dynamic string loading.
We'll also tackle, I think, serializable continuations.
Then we release 0.3.0.
From there I don't want to speculate, but events/IO and threads are next on the hit list.
Questions? This'd be a good time to suggest changes to the timeline...
