On Compiler/Interpreter seperation

[MrNobo1024]

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

[Elian]

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. :)

[chromatic]

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.

[jryan]

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.

[laughingboy]

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

laughingboy

[jryan]

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. :)

[dws]

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.