[Python-Dev] Parrot -- should life imitate satire?

[Gavin Sherry]

On Mon, 13 Aug 2001, Sterling Hughes wrote:

> On Sun, 12 Aug 2001, Paul Prescod wrote:
> 
> > Dan Sugalski wrote:
> > >
> > >...
> > >
> > > Nah, a name change would certainly be in order--we'd have to call it the
> > > ParrotIO system. :) Making the core bits modular is one of the goals, for
> > > no other reason than to make it easy to have someone responsible for its
> > > maintenance and development that doesn't need to be intimately familiar
> > > with the rest of the interpreter system. And so it'll still function
> > > properly when we compile down to native code and don't actually *have* an
> > > interpreter handy.
> >
> > Would it make sense to poll both communities for people interested in
> > helping with this effort and maybe making it a standalone project
> > (perhaps on SourceForge?)?
> >


>     I know that there are some PHP developers who are also thinking
>     along the same lines -- myself for one. :)
> 
>     Also, another area this might reach is into the extension space,
>     we're all developing the same extension for each of the different
>     languages, it would be great to find a way to pool the resources of all
>     the extension developers to create one extension together (ie, a singular
>     XSLT extension, used in Perl, Python, PHP, etc.)

By introducing another layer of abstraction we will most probably decrease
the performance of all languages[1]. 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.

Building extensions to these languages involves a lot of hack work I
agree. The reason for this is that it is merely connecting the wires
between an API and the language of interest. Anything more than that and
you'll be damaging the performance of Perl, Python, PHP...

[1] 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.

> 
>     -Sterling
> 
> 

Gavin