Re: Starting to make things final
At 4:10 PM +0200 8/5/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: ... Python and PHP are > both near-beta ready From which end of the alphabet are you counting, and BTW, which languages's alphabet are you using here. Greek, and from the beginning. I know what state your code's in, and I know what state mine's in. Near-beta's not wrong for either of them. (If you don't count missing builtins, which I'd not count) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Starting to make things final
Dan Sugalski <[EMAIL PROTECTED]> wrote: > ... Python and PHP are > both near-beta ready >From which end of the alphabet are you counting, and BTW, which languages's alphabet are you using here. SCNR, leo
Re: Starting to make things final
At 5:13 PM -0700 8/3/04, Gregor N. Purdy wrote: 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
Re: Starting to make things final
At 05:13 PM 8/3/2004 -0700, Gregor N. Purdy wrote: Did I miss the creation of the compiler-writer list? I need to figure No, we are still holding our breath (and turning blue, purple, green, ...) Btw, I'll poke the Cola rewrite I have here and see where it stands. It gathered a bit of dust in the past 6 months. -Melvin
Re: Starting to make things final
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...
Starting to make things final
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