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).
I think this next round will be the last and, if we do it right, there won't be any user-visible changes. (That is, we'll add the new slots in the interpreter structure but not
Did I miss the creation of the compiler-writer list?
No. We're still waiting on TPTB to get that set up. Believe me, there'll be a big announcement when it happens.
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*?
These'll be the last changes, and hopefully it won't actually change anything we've marked as being set in stone. Part of the reason for the list 'o stuff is to make it so we can reasonably start writing compilers without expecting to have to mess with them because we're fooling with parrot.
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...
--
Dan--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
