Question for you.
You are a lot closer to Parrot development than I am. However as an outsider I've given up on Parrot achieving its original goals. Has there been any sign that what I complained about there is changing? Is there, for example, any sign that we will someday have a version of Python running on Parrot that can pass the Piethon? Like the Python and JPython do, and IronPython almost does.
After this I've wondered from day one how incompatible behaviours between different languages will be handled. Everything from minor discrepancies (eg whether you create new copies of data upon assignment, or upon modification) to major design issues (eg how you break down your error-handling hierarchy). But over time I've become convinced that we'll never get to the point where we have to worry about that.
I'd love to be wrong on this. I really would. But I fear I'm not. | [reply] |
Random thoughts, not necessarily answers...
It is possible for multiple languages to agree on a shared calling convention, and hide all mismatches behind their different object types; that's what the PMC design set out to do, and it's a reasonable solution to that problem. It is also possible to implement things in the most general possible way (e.g. resumable continuations for exceptions), and all high-level languages then build their specific ways based on them.
Based on my own experience in targeting Parrot, and also because I've seen how they are solved in CLR, I think Sam's problems have technical solutions, and the design of Parrot is sound.
However, JVM and CLR are getting much better support for dynamic languages in their upcoming versions (especially CLR, now both VB and IronPython people are pushing it): Features such as AUTOLOAD, per-object methods, and constraints on dynamically-typed variables are finding their way into CLR. It's also possible to add runtime resolution to CLR's already Perl6-compatible static MMD (known as "method overloading" there).
Jython and IronPython exist for a reason -- Python people want to access the existing libraries readily available in both cultures. Furthermore, I think CLR people did a pretty good job in coming up with a BCL (Base Class Libraries) that are larger than Python's core library, so it's reasonably easy to reimplement the standard Python libraries on top of them.
Parrot doesn't yet have the equivalence of BCL, so the language implementor's job is much harder. However, the Tcl people are working on that (e.g. the OS.pmc for files and directories handling), so there is indeed progress.
| [reply] |
