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

[Dan Sugalski]

At 05:51 AM 8/1/2001 +0200, Samuele Pedroni wrote:
>[Dan Sugalski]
> >
> > >IMHO also the fact of not merging the type "ontologies" but carrying 
> somehow
> > >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
>language.

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

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 
JIT JVMs)

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk