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. :)
A review of the current use of PARROT_PYTHON_MODE checks inside of classes/*.pmc shows that the predominant use of this is to override the get_string method to perform python specific formating.
* The Co-Routine pmc also has a part of the inter/next Python
implementation. * The PerlNum pmc also overrides repr, and has a puzzling change to
the behavior of set_number_native(*). * The PerlString pmc is more interesting in that it overrides add and
modulus.For complete compatibility with CPython, a PyInt pmc would also differ in the divide method.
Python is also considerably more strict than the current Parrot PMCs. Addition of a number to a string causes a TypeError exception to be raised.
What we are likely to end up with is a nearly complete disjoint set of PMCs per language.
Inheritance can reduce the combinatorial problem, but it can introduce a precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
- Sam Ruby
