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

[Owen Taylor]

Owen Taylor <otaylor@redhat.com> writes:

> Rasmus Lerdorf <rasmus@php.net> writes:
> 
> > > 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.
> > 
> > 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
> > expecting.
> > 
> > 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
> > issue actually.
> > 
> > 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.
> 
> I think knowledge of the rules for writing bindable libraries is
> much more useful than macro tricks.

[...]

> Etc. If you follow these rules, you get a a library where writing
> bindings for it is a brain-dead task. But still task.  A library like
> GObject that standardizes memory management, and object-oriented
> structures helps quite a bit, but I'm certainly of the opinion that
> the eventual goal has to be
> 
>  - write a library using tools that produce an introspectable
>    descriptions of its interfaces.
>   
>  - Language bindings are automatic and can be done without
>    a compilation step.

Oh yes, and the thing I forgot to mention:

 Write a library and the language bindings will come. The problem
 is getting a vast number of language bindings (the list of 38 
 language  bindings for GTK+ at http://erik.bagfors.nu/gnome/languages.html
 is almost certainly not even complete). The problem is keeping language 
 bindings complete and up-to-date. This is the biggest reason
 why automation is crucual.

Regards,
                                        Owen