All the Perl that's Practical to Extract and Report

Subversive thought for the day

Elian on 2002-05-01T22:51:52

Leon Brocard posted this to perl6-internals and after a conversation with Hugo, it got me thinking. Parrot allows you to load up opcode libraries on demand, and does lexically scoped opcode libraries. What if we...

  • Wrote a set of opcode functions for the JVM ops (there are only 250 or so)
  • Taught the interpreter how to shim properly between Parrot and non-Parrot subs and methods
  • Made dynamically loadable bytecode loaders with some sort of fingerprinting type detection
  • Implemented at least some of the JNI interface?
Scared yet? (And here I thought the big use of loadable opcode libs would be the builtin rezrov interpreter....)

And if we can do it for the JVM, why not .NET?

Oh boy

gizmo_mathboy on 2002-05-02T03:30:49

Wrong. Sick and Wrong. ;-)

Re:Oh boy

Elian on 2002-05-02T05:11:02

But is it bad? That's the big question...

Re:Oh boy

htoug on 2002-05-02T06:54:28

I like the idea! Does that make me sick or bad??

Wow.

Matts on 2002-05-02T07:11:10

I think this is great. I'm picturing that we no longer need to write an XML parser for Perl 6 - just plug in XalanJ... Hmmm...

Of course it's probably a huge job. I imagine it'll go the 80/20 way - the last 20% of those JVM ops will be a bitch to implement right. Are some of those ops GUI ops too?

Re:Wow.

Elian on 2002-05-02T13:46:04

The problem is less likely the GUI ops, as there aren't any (it's all method calls on library code), as stuff like exception schemes and external interfaces.

I'd be happy if just the pure java library code stuff worked. I'm planning on being thrilled if the rest does. :)

Re:Wow.

acme on 2002-05-04T19:48:10

FWIW, we'll be able to do most of the ops quite easily - the JVM is mostly quite low level (not GUI level at all). The main problem is converting the whole API as well. There has been some work on the GNU Classpath project, which might be useful, but yes, the last 20% will be quite tricky ;-)