[Python-Dev] Parrot -- should life imitate satire?
Sun, 12 Aug 2001 19:30:54 -0700 (PDT)
> By introducing another layer of abstraction we will most probably decrease
> the performance of all languages. That is, since the universal
> interface to, given your example, the Sablotron XSLT library is the API
> and Perl, Python and PHP have internals different enough that there would
> have to be a certain amount of glue and translation work between the
> structures of the extension layer and the internals of the interpretter.
It should still be possible to come up with some guidelines for writing a
single extension that supports multiple scripting languages. Especially
for something like Sablotron which isn't that complex. You feed it some
XML and some XSL and it spits back a result. Most of the work in writing
the extension is figuring out how the user-visible API should look and
then translating that API along with its function/method calls and
argument type mangling to whatever the thing that is being glued is
Note that I am not talking about runtime binary compatibility here. I am
talking about source compatibility where potentially big chunks of code
would be very different across the different languages. In an approach
like this I don't see a performance issue. It is more of an education
And with a bit of effort I bet we could come up with enough common ground,
or at least some nifty macro tricks, where people wouldn't feel
overwhelmed by the task of supporting multiple scripting languages when
they sat down to write some new backend library.
Perhaps it would be a good experiment to take some really simple thing and
write Perl, Python, PHP, Ruby, and Tcl extensions for it and compare
notes. See where the overlap is, see where the biggest divergence is, and
figure out if some of that divergence could be eliminated with some clever
>  The situation where you could perhaps increase performance is the
> converse of what is being suggested. Presumably, if it is in the interest
> of language developers to have a unified extension layer, then the point
> of different which language developers want to maintain with with other
> languages is the syntax/grammar of the language.
> As I see it, along this line of thinking it makes sense to look at the
> feasibility of a language system (internals and extension layer) which
> handles plugable scripting engines. As such, the majority of work which
> goes into language development can be concentrated while allowing, to the
> users, automony in their choice of language.
Sure, but now you are back on the holy grail and CLR stuff again. Baby