[Python-Dev] Parrot -- should life imitate satire?
Wed, 01 Aug 2001 00:42:28 -0400
At 05:51 AM 8/1/2001 +0200, Samuele Pedroni wrote:
> > >IMHO also the fact of not merging the type "ontologies" but carrying
> > >both around is a bit scary.
> > It's mildly scary, sure. On the other hand, it's not really any more scary
> > than, say, writing code in COBOL, C++, Basic, or Fortran and calling them
> > from C. Or vice versa. While that's a tad odd, you can pretty easily get
> > used to it, and it works out well.
> > You also don't have to mix languages. That's certainly one of the
> > advantages, but it's far from required. (This is assuming, of course, that
> > there's a performance gain to be had in targeting the parrot back end--if
> > there isn't, then it's reasonably pointless to do so)O
>If one have to call conversion function from Python/Perl code to deal with
>the other ontology or deal with unnatural behavior avoiding mixing languages
>will remain the best thing, also for the problem of reading code in the other
I'm not entirely sure there'll be as much of a mismatch between the
languages as you might think. One thing that'll help on the perl end is the
introduction of optionally typed data--some scalars may be tagged as
integer, or arrays as string only, so a lot of the pain of needing to
handle conversion and impedance matching will already have been dealt with.
>But for C extensions the situation is a bit different, they should target one
>ontology (or not?)
>and then using the extension from both languages will be not that natural.
>And C extension in Python typically extend the ontology, introduce new types
It's possible there'll be a bigger mismatch, but I'm not that sure here,
either. (Though I'm stumbling around a bit here, as I've no experience
writing Python extensions in C) Some classes of extension will be
essentially language neutral--an array's an array's an array and, while
some of the details are interesting (like whether it's typed or sized)
those are, ultimately details. Important ones, to be sure, but far from an
New types are a bit more of a challenge. Some things, like declaring
methods or overloaded behaviour, are also reasonably small details. Other
things, like things I'm not thinking of, are less so.
Don't forget I'm also looking at this from the bottom up, not the top down.
Parrot's going to be a dynamic language friendly, mildly OO CPU. From that
level, these (And I'd get fancy here, but I don't know how to do so without
embarrassment in Python):
$foo->bar($a, $b, $c)
foo.bar(a, b, c)
are pretty much syntactically equivalent, and the fact that perl declares
methods in packages and handles inheritance on a per-class basis via the
@ISA array and Python does something else entirely syntactically is pretty
straightforwardly abstractable, and isn't hugely important *for the
execution engine* as long as that abstraction is sufficiently powerful.
While Perl and Python aren't quite just ALGOL with funny hats, they're
really not that different from each other from the level I'm working at.
Certainly far less different than they are together from, say, LISP or
Forth, or even .NET. (I expect we face similar performance issues with
.NET, and the JVM, as neither seem particularly fond of dynamic languages.
Though I do see that Jython gets pretty good performance from some of the
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
firstname.lastname@example.org have teddy bears and even
teddy bears get drunk