Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

On Compiler/Interpreter seperation

by MrNobo1024 (Hermit)
on Aug 18, 2002 at 21:29 UTC ( #191022=perlmeditation: print w/replies, xml ) Need Help??

In perl5, the compiler and interpreter are both inside one program, so programmers can just type perl and not have to worry about extra files. This is in contrast with Java, where the compiler (javac) reads a .java source code file and creates a .class bytecode file, to be used with the interpreter (java).

I have read that perl6 will instead take the Java approach to this and keep the interpreter, currently dubbed "Parrot", seperated from the compiler.

I can see two possible problems with this, however:

  • It would be annoying to have to type type perl6 > foo.pbc; parrot foo.pbc every time your program changes.
  • The eval "string" function. Since the string might have variable interpolations, it cannot be compiled until runtime. In perl5 this is not an issue, since the interpreter can just call the compiler again when it encounters eval "string".
The first problem could be solved by automatically execing parrot after compilation, but I have no idea about the second. It could exec the compiler again, but the overhead of starting a process would make it far slower than in perl5. Anyone care to enlighten me on this?


Replies are listed 'Best First'.
Re: On Compiler/Interpreter seperation
by Elian (Parson) on Aug 19, 2002 at 00:55 UTC
    You're both right and wrong.

    At the moment, the compilation and execution phases are separate. When we ship the final code, they'll be combined.

    It was easiest to have them separate to begin with--we built a standalone assembler that could generate bytecode files that the interpreter can mmap in an directly exectute, which made it possible to get up and going quickly. The languages that have been implemented on Parrot so far have more or less gone that route (well, except for the ones that are true interpreters, like BASIC and Befunge) because, well, it's easiest. The compilers can be written in anything, and Parrot doesn't need to have a functional parser built in.

    We're moving to an integrated system where the compiler and interpreter are together in the same executable--necessary for perl's eval, for example. It's more complex, though, so it's coming along slower. That's OK, since we have more than enough to keep us busy as it is. :)

Re: On Compiler/Interpreter seperation
by chromatic (Archbishop) on Aug 19, 2002 at 00:15 UTC

    Per my understanding of Apocalypse 5, it'll be possible to change the grammar rules of Perl 6 at runtime. This leads me to the strong belief that the parser, lexer, and compiler will be built on Parrot. If this is the case, dumping Parrot bytecode will be optional.

    Elian will probably be along to correct any misconceptions, though.

Re: On Compiler/Interpreter seperation
by jryan (Vicar) on Aug 19, 2002 at 00:08 UTC

    The perl6 prototype currently works similar to perl5, where you can simply type ./perl6 and it will run just fine. This is because the prototype works in 5 stages:

    1. Generate a parse tree.
    2. Decipher parse tree, optimize, and output assembly code
    3. Assemble
    4. Compile
    5. Run

    This has many advantages. For instance, you can stop at one step, and pick up again later at it (e.g. stop after compilation to create an executatble). How it will work \ in the "Real Thing" hasn't been decided yet. However, even if the entire process takes longer than perl5's, thats not really a problem. If you really need the speed, you can stop at stage 3 or 4 to create a program that skips the slower steps.

      I'm curious: what's the difference between stage 3 (assembly) and stage 4 (compilation) ?


        Sorry, I wasn't too clear there. Step 3 (Assemble) assembles (using the assembler parrot assembly into bytecode. From there, one of two things happens: either the program is compiled into an executable, or is run. :)
Re: On Compiler/Interpreter seperation
by dws (Chancellor) on Aug 18, 2002 at 23:07 UTC
    It [the eval "string" function] could exec the compiler again, but the overhead of starting a process would make it far slower than in perl5. Anyone care to enlighten me on this?

    Invoking a separate process to compile a string into Parrot would have serious performance implications. To avoid losing the power of eval, the compiler would need to be in the same process. I think it's that simple, unless someone has come up with a clever innovation.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://191022]
Approved by sm3g
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (10)
As of 2018-06-25 12:57 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.