Hi Affijn,

As I gradually learn how Parrot works, I see that perhaps the idea of
decompiling byte-code into language ___ is only a pipe-dream. But the
point still remains--using the fact that one *could* mix languages X,
Y, and P into your company's source tree is a very weak argument for
Parrot/Perl6. I would say it is a non-argument.

As you point out, it can already be done with Inline.pm & friends. In
fact, it can be done even more blatantly with backticks. It has long
been possible to do stuff like this:
 $a = `/usr/bin/java foo.class`;
 $b = `/usr/bin/php bar.php`;
 $c = $a + b;

The reason this would make an IT Manager cry is not (promarily)
because it is slow (etc, etc), it also means she now has to keep a
Java/PHP/Perl programmer around and happy whenever one of three
different languages might throw a buggie.


On 26/05/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:
"Michael Mathews" schreef:

> [compile down to a *language independent* format]
> So does that mean I can write a module in Perl 6, deliver it to Mr.
> Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
> Python (or JavaScript, or C, etc), edit it, and then compile it back
> into working byte-code again?

No, compiling to bytecode is like a one way street: you will probably
not remain recognizable when you drive it in the opposite way. It is
less hard to go from Perl6-code to Python-code or rather v.v.

But there is no need for all that. Think about the libraries compiled
from C-code that are now linked with Perl5. You can do something
similar with Parrot: create libraries that can be efficiently "linked"
with code written in other languages (that compile to Parrot).

Mixed language source code, even cleaner than the current Perl5 with
Inline.pm, is another feasibility.

Affijn, Ruud

"Gewoon is een tijger."

Reply via email to