Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

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 foo.pl 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.pl > 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?

--MrNobo1024
s]]HrLfbfe|EbBibmv]e|s}w}ciZx^RYhL}e^print

Comment on On Compiler/Interpreter seperation
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.

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 script.pl 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) ?

      laughingboy

        Sorry, I wasn't too clear there. Step 3 (Assemble) assembles (using the assembler assemble.pl) 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 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 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. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://191022]
Approved by sm3g
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (18)
As of 2014-08-01 17:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (33 votes), past polls