Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Why Perl 6 is taking so !@#$ long

by dragonchild (Archbishop)
on Feb 28, 2006 at 15:00 UTC ( [id://533364]=note: print w/replies, xml ) Need Help??


in reply to Re: Why Perl 6 is taking so !@#$ long
in thread Why Perl 6 is taking so !@#$ long

I haven't been following P6C other than to scan the summaries. I certainly don't have the chops to understand even half of what's going on down in the trenches. So, if you're concerned about the future of Parrot, then I'll be concerned.

My question is this - Perl6 can't be written in Haskell. So, if it's not Parrot, who's going to write the P6 VM and in what?


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^3: Why Perl 6 is taking so !@#$ long
by duff (Parson) on Feb 28, 2006 at 15:22 UTC
    My question is this - Perl6 can't be written in Haskell. So, if it's not Parrot, who's going to write the P6 VM and in what?

    Um ... who says perl6 can't be written in haskell? Who says that perl6 can't be bootstrapped into existence using pugs and then use perl6 to write the "real" compiler (maybe it emits C code or even <insert favorite language here> code).

      The requirement that says "Must run on every OS known to Man, and then some." Writing C that's that portable is hard, but I don't think I need to tell you that. One of the features I haven't mentioned is PGE, which is, essentially, the parser. Patrick Michaud is currently writing it in PIR. Who's going to write it in C? I don't know enough portable C to do so ... finding someone who knows enough, has the time, and is interested is going to be a ... challenge.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        Patrick's original implementation of PGE was in C. Now that he's got a nifty PIR implementation, it shouldn't be too much work for him to create a C implementation again if the need arises. As I understand it, the main problem is that the PIR implementation utilizes continuations quite a bit, so those would have to be "ported" to C as well to keep the implementation simple yet equally as powerful.

      I think the main problem is that any VM written in a higher-level language will be too slow for practical use. That's why the Java VM and Mono are written in C (and .Net is written in C++?). The compiler doesn't matter so much, it's only involved once in the execution process and can be written in a higher-level language, but for the actual runtime you need to get as close to the metal as you can which means writing it in C.


      All dogma is stupid.
        I think the main problem is that any VM written in a higher-level language will be too slow for practical use.

        Take a good look at the performance of alternatives to C in the benchmarks at the GCS when doing VM like things.

        In many, maybe most cases, C is left behind by compilers for languages like Haskell, Erlang, OCaml, SML, and my favorite Clean.

        When you combine their deeply analysing and heavily optimising compilers, with their freeing the programmer from so much of the low-level housekeeping like memory management, using almost any of them to create a VM interpreter would be a win in terms of productivity.

        It may be that you would want to hand code the dispatch loops and JIT compilers in C or even assembler--maybe--to squeeze out the final ounce of performance, but you retain those generated by the compiler/hll for debug and benchmark purposes.

        C does can produce very fast compiled code--in the hands of exceptionally proficient programmers--but that performance comes at a huge cost in terms of productivity. Coding yet another set of memory management, allocation/deallocation infrastructure, debug and trace routines et al. And when things do go wrong it requires a special breed of immensely skilled and dedicated practitioners to investigate and track down the causes.

        Most of us here recognise the benefits of using high(er) level languages with in-built memory management and revel in the freedoms that gives us. It seems silly to eshew those benefits for writing the vast majority of the infrastructure and kernel of a VM. Better to write in a HLL for reliability and productivity and reserve C for tuning the performance critical parts.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Haskell could be key
by Anonymous Monk on Mar 09, 2007 at 04:37 UTC
    Perl6 can be written in Haskell as there are already compilers for almost every OS out there.
    Check out the current implementations.

    Though I have to point out that Pugs currently depends on the cutting edge Glasgow Haskell Compiler (GHC) for some features but most of these will be incorporated into the new Haskell-Prime standard and therefore propagated to all implementations.

    Anyways, one of the goals of Perl6 is to be self-hosting. Check out this Pugs overview.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://533364]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (9)
As of 2024-03-28 10:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found