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

[Sterling Hughes]

On Sun, 12 Aug 2001, Rasmus Lerdorf wrote:

> > 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.
>

    Well -- Sablotron is more of an annoyance in this regard than
    anything -- if you want to support SAX, Scheme, error handling, log
    handling and such, you need to register a million callbacks and then
    have each of these callbacks either do something useful, or call
    some user space function. puhhhh.

    The PHP-XSLT extension, all in all is 2525 lines of code, Makefiles,
    and explanations, 2525 more than I would've liked to write
    (http://cvs.php.net/cvs.php/php4/ext/xslt)...

    Using PHP-Sablotron as an example is something where having a
    couple of minds is better...  The first version of the extension
    (http://cvs.php.net/cvs.php/php4/ext/sablot), left, uhhmm, something
    to be desired -- the api was a bit hard to understand, and it made
    code maintainability within the extension something close to hell.
    Perhaps if there were a couple more minds working on the extension,
    some of the mistakes of the original version might not have been
    present (perhaps if I had slept the weekend that I wrote it, that
    might have happened as well, who knows? :)

    Anyway, just counting now -- 4530 lines of "stuff" :) have been
    written on the PHP end of things for bring sablotron support in
    (actually, the newer XSLT extension will also support libxslt and
    Xalan, so some of its bloat for those extra libraries, but..)  I
    imagine that on the Perl and Python ends at least 1,000 lines of
    code have been written on each side.  Wouldn't it be spiffy if this
    only had to be done once?  Hell, if there's a singular extension
    api, as you say, vendors may just write to that spec, and we don't
    have to worry about writing it at all!

> 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.
>
> 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
> tricks.
>

    I think this would be interesting at least -- I'll write the PHP
    extension (Hell, I already have,
    http://cvs.php.net/cvs.php/php4/ext/zip, it don't get easier than
    that :)

    -Sterling