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

[Owen Taylor]

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.

Writing down the rules would be a big project, though the set
of rules isn't that big. A few important ones are:

 - User data stored with a structure should have an associated
   notifier.

 - Callback functions must take not just a function, but 
   a function,user data, destroy notifier combination.
  
 - Data structures should be one of:

   * Immutable and refcounted. 
   * Copy by value.
   * Copy by reference, reference counted, with destroy
     notification and a user data facility for maintaining 
     persistant language <=> library associates.

 - Keep the C simple. Opaque structure with accessors is
   the ideal, structures initialized with magic macros
   one of the worse offendors.

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.

Regards,
                                        Owen