Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I was reading this post, regarding porting rakudo to different platforms.

Well after reading up a little bit upon nqp what I could understand is that its basically awk like utility(matches a pattern and executes something for that match) with grammar support and facilities to generate AST. While little documentation is there on NQP, understanding how its built is itself a little difficult. Reason being its bootstrapped, so I have to understand it first, to understand it. Which I don't.

Now when its mean't that rakudo will run on v8, ideally it means writing NQP to bootstrap itself(In JavaScript) along with generating JavaScript code. How exactly is this entire bootstrapping done? Generation of JavaScript code(I understand parrot has facilities to do it,but in v8??)? Can somebody please enlighten.

Replies are listed 'Best First'.
Re: Backend diversity for Rakudo
by moritz (Cardinal) on Aug 17, 2010 at 07:26 UTC
    NQP implements a subset of Perl 6 that is useful for writing a compiler, and that runs well on parrot without the need for built-in functions (except the regex engine).
    How exactly is this entire bootstrapping done?

    Since NQP transforms its input to a format called PAST, the first step will probably be to write a PAST compiler that emit JS. Since the PAST compiler is now written in PIR, the bootstrapping plan might look like this:

    1. Re-write the PAST compiler in NQP
    2. Add a variant of the PAST compiler that emits JS
    3. Run the NQP-on-parrot on itself, emitting javascript
    4. reiterate until it works
    5. Profit!
    Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
[reply]
        Rewritten, or manually translated.

        Jonathan has a plan for the meta model, and wants to prototype it in .NET anyway, so at least for the planned .NET backend we have a way forward.

        Update: After some discussion with jonathan, I should clarify that the meta object model is going to be moved from Rakudo to NQP, and built on top of some primitives, which are rather portable between different VMs. So the hard part of the metamodel port need to be done only once.

        Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
Re: Backend diversity for Rakudo
by Anonymous Monk on Aug 17, 2010 at 08:47 UTC

    Is there a reason, why rakudo should target many back ends? Ideally the parrot one should be completed and then it could be ported to other VMs. Diversifying so quickly will slow down an already slow process. If you target two more extra back ends its like-time-taken-to-implement-one multiplied by 3.

    If I'm not wrong many such projects already exist eg: Sprixel, Niecza etc. Which are targeting other back ends. Why reinvent the wheel again?

[reply]
      Is there a reason, why rakudo should target many back ends?

      Yes. Diversity in itself is a worthy goal, and there are some technical reasons, like parrot not properly supporting any threading, attracting developers from the target platforms, and interoperation with libraries that run on the alternative target platforms.

      Ideally the parrot one should be completed and then it could be ported to other VMs.

      What is this "completed" you are talking about? Do you know of any software that is both alive (ie actively developed) and "completed"? Linux is being developed since 1991, and still not completed, and I don't hear any complaints about it targeting multiple platforms.

      If you target two more extra back ends its like-time-taken-to-implement-one multiplied by 3.

      Only for backend specific code.

      If I'm not wrong many such projects already exist eg: Sprixel, Niecza etc.

      Neither Sprixel nor Niecza are a Rakudo port to a different platform. They have rather different goals than Rakudo. If we can re-use some of their code, we will. Also, would you care to elaborate on the "etc." part?

      Why reinvent the wheel again?

      Which wheel do you think are we re-inventing?

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
        ... there are some technical reasons, like parrot not properly supporting any threading...

        To me, that argues for developer focus on making Parrot support parallelism and concurrency.

        Only for backend specific code.

        There's the problem, though. Either you write to a bland portability layer which supports the sanest bare-bones intersection of features across every platform to which you eventually want to port (and to have any hope of performance you have huge, platform-specific optimization layers which poke through the bland layer of pudding) or you spend more time porting between platforms and less time sharing code.

        If you think you can attract enough black magic developers on these alternate platforms interested in discovering, creating, and maintaining the layers of jiggery-pokery necessary to make Perl 6 perform worth using, your best approach is the pudding layer.

        Which wheel do you think are we re-inventing?

        Any runtime for Perl 6 is going to end up looking a lot like Parrot.

        ("My goodness, chromatic! Wouldn't it be easier to port Parrot to these other VMs?" Why yes, yes it would.)

[reply]

        Ok, whenever this word 'completion' crops up there is great deal of confusion as to what is complete. Complete in the sense Perl 5 is complete. Complete in terms of stability, spec compliance, production readiness, availability of libraries/documentation and usability. Complete not in the sense of halted development. Both Linux and Hurd are being actively developed, but Hurd is not complete in the same sense Linux is complete.

        Everything else you mentioned is perfectly acceptable. Probably you can have a second look at the word 'Complete'.

[reply]
        Do you know of any software that is both alive (ie actively developed) and "completed"?
        I was going to say TeX, but your sidemark "actively developed" and "completed" are mutually exclusive.

        IMO, there's a difference between being "alive" and "actively developed".

[reply]
        Niecza targets the .NET CLR, rakudo aims to target the same in the future(???, Is it so?). What is the difference we are speaking about here? Just the code and the way niecza and rakudo implement them? For the user its the same Perl 6 syntax and semantics running on the same platform.
[reply]
      Is there a reason, why rakudo should target many back ends?

      The only worthwhile reason I've heard is "People want to do it." (Targeting multiple backends hurt Pugs more than it helped.)

      Diversifying so quickly will slow down an already slow process.

      Only if you assume that developer time, interest, and ability are fungible. Porting NQP-rx to .Net may attract people who have no interest in Rakudo on Parrot. Porting NQP-rx to LLVM may attract people who have no interest in Rakudo on the CLR or Parrot. Porting NQP-rx to the JVM may attract Larry Ellison.

[reply]

        Frankly speaking most of the Perl 6 implementations in the Past look like "me too" projects. Start with something just because some body else is doing it, ultimately get overwhelmed by the task and abandon it. This is what fundamentally happens when you want to do it just for sake of wanting to do it. The moment there is some technical barrier the motivation evaporates into thin air.

        Apart from a few serious attempts like Parrot, Pugs and Rakudo. Other projects have provided good feedback but that was not the aim of those project, was it?

        Focus is the name of the game for large projects like this. Parrot wanted to be a good runtime for Perl 6 but what did it end up being? Run time for a near dozen languages but slow with a suboptimal GC. Now Rakudo wanted to run on Parrot but is now aiming to run couple of other backends. The focus keeps dividing and ultimately time passes on and nothing worth while is achieved. People get frustrated and find something else no matter how much you try convince them.

        It's not difficult to imagine all successful projects in the open source community example Linux, Perl, Python started as small humble projects but scaled over a period over the time. Alas, that never came to happen with Perl 6. One very large ever evolving spec, with implementations constantly loosing focus and jumping anything new on the market. Will we have to wait for another 10 years while this comes out clean,or never?

[reply]

Back to Seekers of Perl Wisdom