There's a couple of reasons why Perl5 doesn't run on virtual machine X, be it Java or something else.
-
Limited benefits. Perl is already extremely portable, and Perl can already access foreign libraries (XS, Inline::).
-
Performance problems. Perl is highly optimised. Those optimisations would not be immediately available in a port.
-
No formal specification. Perl is what perl runs. This and Perl's continual growth means that Perl is full of subtle behaviours and people rely on them. Each of these would need to be identified and replicated.
-
Too much work needed. A good portion of Perl actually lives in modules, and those are often written in C. In Java's case, you could access Java's libraries instead, but writing Perl isn't the same thing as writing Java in Perl.
-
Limited desire to spend the effort. For the above and other reasons, there is no interest in actually doing the work. For example, perlcc was finally dropped from Perl for being constantly out of date
That said, I believe work is actually under way for a Parrot port of Perl5. Don't quote me on that.
Update: I'd like to add a thought. We can discuss all the reasons for and against, but it really boils down to whether there exists someone who wants it enough to go out and do it. As far as I know, there is no such person for a Java port of Perl.
| [reply]
[d/l] |
Thanks, and my question is answered.
Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
| [reply] |
Parrot was born
from the desire to target Perl6 to a VM separate from the language front-end and the realization that no contemporary mainstream VM really had the chops to support languages as highly dynamic as Perl to the level desired by the Perl6 team.
There are no fewer than two Python implementations using Parrot as a target, although one (Pynie) has scant details as linked from the Parrot web site and the other (Pirate) seems to be sporadic and sleepy if not defunct.
There are also a long list of other languages that have been implemented to target Parrot. Those projects are in various stages of completeness. Some are undoubtedly just proof of concepts or curiosities (ook, bf, Punie, befunge, lolcode) rather than projects aiming at producing production language tools. However, with no fewer than seven Lisp (Lisp, Arc, and Scheme) projects, two for ECMAScript, two for PHP, two for Lua, and a handful of other tools I'd say there's a good chance something useful is going to be on top of Parrot besides Rakudo (the Perl6 on Parrot project).
Perl6 is also a specification-based language design. While Perl5 may never run on another VM (although, as ikegami says talk has been heard of "PONIE" -- Perl5 on Parrot), Perl6 is meant to be a list of specs, a test suite, and as many front-end and back-end implementations as can be developed to pass that test suite. Since Perl5 (actually, Perl 1 through Perl 5) grew sort of piecemeal around the implementation, it makes things very difficult to have separate implementations which work the same.
Perl6 was designed with multiple different source-compatible implementations with the same semantics in mind. That means you may very well see Perl6 running on the .NET CLR, the JVM, LLVM, Neko VM, compiled directly to x86 object files, or something else entirely. One implementation is the aforementioned Rakudo. The complete list of implementations includes Pugs (written in Haskell), SMOP (written in C), KindaPerl6, and v6.pm (Perl6 subset on Perl5 via modules). Eventually hopefully all of these projects will provide Perl6 implementation frontends and backends that meet the specs along with other backends.
If you're looking for Perl on a VM other than the one currently used by Perl5, then you're probably going to be pleased with that aspect of Perl6. Getting Perl5 onto another VM and retaining cross-compatibility is from what I understand a Herculean task, though, and one that won't be worth the effort if you'd just turn around and use Perl6 anyway. Attacking the backend target compatibility issue at the same time as changing the language syntax is a good idea. Let the frontend and backend specs be built together, rather than specifying what a Perl5 backend must do then changing the frontend for Perl6. | [reply] |
| [reply] |
Inline::Java allows Perl to access Java, but the OP asked about a Java implementation of Perl.
| [reply] |
ikegami,
What about a perl implementation of Java (PJVM)?
| [reply] |
If perl5 can run in perl6, and perl6 can run in VMNAMEHERE, why is this infeasible? | [reply] |
The answer is yes. But it is not compete.
http://bsfperl.sourceforge.net/ | [reply] |