http://www.perlmonks.org?node_id=1043034


in reply to Re^6: v5, a reimplementation of P5 (was Re^5: A "Perl-7" that I could actually USE right now)
in thread A "Perl-7" that I could actually USE right now

How hard could it be to write the thunking layer?

Keep in mind the current mindset is that everything has to be portable across all of the (hypothetical) backends that Rakudo (hypothetically) supports, so writing a thin embedding layer in C won't do. You have to write it in NQP and then hope that the backend allows you to invoke C functions in an efficient way. That's C for Parrot, JNI for the JVM, something like P/Invoke for the CLR, wishful thinking for v8, and magic unicorn fairy dust for MoarVM.

It's gotta be easier than recreating P5 + XS + everything else.

If P6 is optimized for -Ofun, then plumbing and maintenance and packaging and all of the other pieces of finish work that aren't glamorous must not be fun.

  • Comment on Re^7: v5, a reimplementation of P5 (was Re^5: A "Perl-7" that I could actually USE right now)

Replies are listed 'Best First'.
Re^8: v5, a reimplementation of P5 (was Re^5: A "Perl-7" that I could actually USE right now)
by diakopter (Novice) on Jul 10, 2013 at 22:14 UTC

    lend me some of your dust ...

      Oh, I already wrote code to handle the sharing of entities between Parrot-hosted languages and Perl 5 (the hard part was walking between the two very different memory management strategies of garbage collection and reference counting). I'm sure that code's been lost to one of the annual purges, however. I have no desire to rewrite working code for the sake of P6's current implementation fad—but good luck doing that in a cross-platform way in NQP, or handling internal encoding and decoding in an efficient way, or dealing with system calls, or managing library paths, for example.