Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • question - do XS modules load parallel to the jvm, or are they off the table entirely?
    • Java uses JNI which is its native extension mechanism. I'm pretty sure at least basic XS modules could be compiled using a compat layer that provides XSUB.h and perl.h definitions but calls the appropriate JNI functions instead.

      (and no, I'm not volunteering)

    • It was my understanding that, like Ruby, the C extensions won't be available. That being said, I don't know that this is impossible, but it's not planned as far as I'm aware.

      Those XS extensions written in order to interface with different C libraries might be problematic. Those written for speed would be suitable candidates for rewriting as Java approaches the speed of C (and in some benchmarks can exceed it due to Java's optimizations).

      • i guess that my pipe dream of a spidermonkey perl module running inside the jvm isn't going to happen. oh well, at least there's still rhino.
  • In case there are people interested, I have started a similar-yet-different project.

    At the moment I am concentrating in writing a Perl parser in Perl (it can currently parse itself) and writing a .Net backend for it using DLR (there is nothing working yet, but I hope to have something soon).

    Check out http://github.com/mbarbon/language-p/tree/master [github.com].

    in time I hope to have something like PyPy: a complete Perl runtime written in Perl and recompilable to any lower level platform (I am dreaming to support

  • new has become a keyword.

    I can't see why that'd be necessary. For Perl 5 object semantics (overloading, AUTOLOAD, UNIVERSAL, dispatch) you need a thunking layer between Perl objects and Java objects already. If you want interoperability between them, you need the same thunking layer.

    In my mind, the right approach is to translate all bless REFERENCE syntax into metaobject calls, not to add new syntax. The Perl 5 data and object models are flexible enough that you can implement them in terms of Java mor

    • I agree it's not necessary to make new a keyword, and I don't think it's desirable. I wasn't thinking about making JVM objects available at the Perl level, but if you wanted to do that, I'd propose a new keyword instead: javanew, or something like that. Then Perl can be Perl, and if you want to get to JVM objects you can.

      Come to think of it, even better than a keyword might be a module. It'd have to be a very special module, though, something akin to DynaLoader.

      Anyway, great project! It's been done (and

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • But what do you do if you want to instantiate a Ruby object? Create a rubynew constructor? New constructors for every language out there? It gets unwieldy after a while.

        • Add to that the fact that adding keywords specific to an implementation diverges from the reference implementation. Library fragmentation is bad enough; as Microsoft and Sun about that sometime (though the latter has been happy to inflict it upon other languages).

          • You'd have to talk to the people putting it together. At some point, there's probably going to be some divergence. Perhaps they can also get rid of legacy stuff that's holding Perl back?

            • Perhaps they can also get rid of legacy stuff that's holding Perl back?

              I have no hope of that experiment succeeding until p5p consensus finally acknowledges that its long dalliance with DarkPAN-paralyzed stagnation has failed, miserably. (Perl 5 doesn't have classes in 2009?)

              Of course, a successful Perl 5 on the JVM (or even Parrot) might demonstrate that the sky hasn't fallen, and both people who care about running code last modified in 1995 on a release from 2009 can well and truly port it themselves (

        • In that case, I like the idea of having to go through a module, better. When you want a Java object, you have to explicitly go through a Perl module that provides that access. When you want a Ruby object, similar story, different module.

          I had no idea you were trying to provide access to objects in so many different languages...

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • First of all this sounds like a very exciting and interesting project.

    But I have to agree with chromatic that, if you want to support as much of Perl as possible, you'll probably need some kind of indirection layer, both for the object system and for things like local $a[2] = $stuff; (Or is that handled in the SV structure?)

    Another piece of interest - does it support BEGIN blocks (and if not, is that planned)?

  • I posted this blog entry into reddit and this link was posted in comments: Considerations on Porting Perl to the Java Virtual Machine - master thesis [ebb.org].