On Sun, Sep 23, 2001 at 03:52:13PM -0400, Mathieu Bouchard wrote:
> Compiling Python and Ruby source-code to Parrot byte-code won't ever
> generate any integer-specific, string-specific, or float-specific opcodes,
> except to the extent required by the implementation of Python's and Ruby's
> object systems in Parrot. (and also except if someone writes a really good
> optimiser.)
> Python's and Ruby's ideas of what are Integers, Floats and Strings would
> have to be implemented directly in the Parrot assembly language to take
> advantage of those bytecodes (and therefore of interoperability with
> Perl).

You're right and you're wrong. Let me try and explain.

There are very few ways of adding two integers together. Well, to be honest,
there are precisely two ways: you can add two integers together and get either
the right answer or the wrong answer. Once a language acknowledges that it is
dealing with pure, honest-to-God integers, then it is fairly easy to compile
down to integer-specific opcodes. If your code honestly wants to add together
two integers and Parrot_op_add_i doesn't do what you want, then something is
wrong with the universe. So you're wrong about that - it *is* possible to
generate opcodes which are non-language specific but are integer-specific. It
all depends on how well you write your compiler, and whether or not it chooses
to use the integer-specific ops available.

You are right in the sense that, of course, we don't believe everybody's
strings (or floats, or whatever) should work in the same way. Python's strings
and Perl's strings are very different. (I should look into Ruby's strings, to
see how they work, but I regret to say I haven't been able to do so yet) 

In this case, the compiler might not try to use the common string opcodes (I
say "might not" rather than "will not" because there are still things which
all languages will want to do - get the length of a string in character or
bytes, for instance.) but will instead wrap its strings as PMCs, Parrot Magic
Cookies. 

Don't feel put on, this is something that I'll expect Perl strings to do as
much as Python or Ruby or whoever else's strings. Everyone who's doing Clever
Stuff, and that's most languages, should use a PMC.

Let's take a concrete example. Suppose you want to increment the value of a
string; this is perhaps a bogus example, because (as I understand it, and I
could be wrong, but if I am, s/Python/some other language/g) strings are
immutable in Python and so a Python->Parrot compiler should never ever
generate this code. But let's say it did. 

If we use a PMC instead of a STRING, then we achieve language abstraction.
Watch. In Perl, '$a="y9"; print ++$a' produces "z0". The Parrot assembly would
look like this:

    set P1, "y9"
    inc P1
    print P1

This would cause several functions to be called; let's concentrate on the
increment. The operation would essentially be implemented as

    (P1->vtable->increment)(P1);

Since in our example, P1 is a Perl scalar, P1->vtable would point to
Parrot_vtable_perl, and P1->vtable->increment would point to the function
Parrot_vtable_perl_string_increment (or similar) which comes from the
libperlvtable.so library which we've linked in. This function would take the
value, "y9" and then do a Perlish increment, transforming it into "z0".

Let's use the same assembly:
    set P1, "y9"
    inc P1
    print P1

but assume that P1 has a different vtable pointer and a different set of
functions linked in. Now the operation would be the same:

    (P1->vtable->increment)(P1);

but this time P1->vtable->increment would now be the function pointer
Parrot_vtable_python_string_increment from libpythonvtable.so. This would
probably abort with an error message to the effect that you can't do that
to strings, and the compiler writer should be shot, but that's not the point. 

The point is that by using PMCs and plugging in vtable pointers appropriate
to the behaviour of the PMC that you require, you can achieve language
abstraction using Parrot's current design.

I hope that makes it clear. :)

-- 
The PROPER way to handle HTML postings is to cancel the article, then hire a
hitman to kill the poster, his wife and kids, and fuck his dog and smash his
computer into little bits.  Anything more is just extremism.
        - Paul Tomblin, in the monastery.

Reply via email to