Leopold Toetsch wrote:
Michal wrote:
Hey all,
Why does --python mode modify the behaviour of coroutines?
Guido is to blame. Python generators/coroutines work like this:
iter = coro() # first time calling for x = iter() ...# iterate
And that's what Parrot is doing too with the --python switch. But there is more ugliness: Python returns "None" if the generator is left through the end and a StopIteration is thrown (which you have to catch).
That's all really messy and needs definitely some cleanup. OTOH it was the most straight forward translation of Python bytecode.
Ultimately, it would be nice if Perl and Python could run on the same instance of Parrot; this would be pretty much be precluded by switches such as this.
Pirate is currently running with --python due to a number of Python specific behaviors introduced into a number of PMCs. I'd like to revert back to running without the --python switch... which would require the introduction of a number of new Python PMCs.
As would I. I'd like to hold off until after 0.1.1 gets released this weekend (give or take) but after that I'm all for diving into this and getting it nailed down. If it comes together quickly we can put out a 0.1.2 release with everything fixed up.
The number of such PMCs would likely number between one and three dozen. I'm quite willing to work on a series of patches that adds these in stages.
Cool. One of the things we should do, and if one of the Ruby guys wants to chime in that'd be great, is to see where we've got areas of commonality so we can see about sharing most of the PMC code with common parent classes or something.
Are Python specific PMCs the right way to go?
Mostly, yes.
What are the implications of having a PerlString and a PyString? I guess ultimately we are going to need to decide what to do with things like:
mmd_lookup(MMD_ADD, PerlString, PyString)
Will the combinatorics involved in adding a new language overwhelm us?
Possibly, yeah. The MMD system should do inheritance, though that's not in right now. That ought to cut down on the combinatorial problem.
It's also likely, for better or worse, that the various language base types will have minimal knowledge of each other. There's not much for that, unfortunately -- if we have a system with 50 or 60 basic types (factoring in the perl 5, perl 6, python, ruby, and basic parrot types) there's going to be a lot of code to write.
On the one hand that's going to be a pain. On the other, it's a pain because we get functionality (i.e. data sharing across langauges) that we didn't have before, so I can live with that. :)
Should the Python specific behavior be removed from the Perl PMCs? If so, when?
Yes, and right after we release 0.1.1. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
