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: #!perl5 $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. --michael 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."
