Is Perl a compiled or an interpreted programming language?

Is P开发者_JAVA技巧erl compiled or interpreted?

You aren’t going to get a definite answer, because you haven’t provided a definite question.

Perl is always in one of two states: it is either compiling, or it is executing. That’s why you see talk of “at compile-time” vs “at run-time”. Normally, you get one compile phrase followed by one execution phase, but it need not be that way.

These two phases can also trade back and forth. An eval STRING is a way for the interpreter to call the compiler (so too therefore are do FILE and require). A BEGIN block is a way for the compiler to call the interpreter (so too therefore are use and no).

When you run perl -c, you omit the run-time phase. There are various ways to skip the compile-time phase, but none of them is particularly convenient, or commonplace. Apache’s mod_perl only compiles scripts once but executes them many times. If you use the Byteloader, you can do the same. Et cetera.

The correct answer to whether Perl is compiled or interpreted is simply YES.

Well, that depends on what you mean by a compiled language. Maybe this is why googling did not bring forth a clear answer to your question.

One viewpoint is that compilation means compiling from a source code description to another, i.e. code generation.

If we accept these premises, then Perl 6 can be compiled and Perl 5 and older are interpreted languages.

Perl 6 is specifically compiled to Parrot bytecode. Perl 6 is therefore a properly compiled language, in the same way say, Java is.

Perl 5 and older parses the Perl source code to an internal list or tree, but I don't think it should be called a proper compiler, except maybe in a theoretical sense. It does not output any bytecode, assembly or real machine code usually associated with compilers. The parsing stage of Perl to check Perl syntax used to be called "compiling" the source. It is used to check the syntactical validity of a Perl source file without running it.

It is invoked as:

perl -c myprog.pl

But if you look at the help for Perl options, -c actually stands for "check".

-c                check syntax only (runs BEGIN and CHECK blocks)

^{(To further complicate things, Perl 5 had support for writing out internal bytecode but it was removed in version 5.10. Presumably because it was buggy, I don't know.)}

On the other hand, if you argue that compilation is the act of parsing a source tree into any other kind of representation, well, that parsing makes Perl a compiled language. Perl must completely parse a source file before it can start executing it. By this definition, any language which can start executing a source file immediately before parsing would be an interpreted language.

A third way to look at this is from how these words, "interpreted" and "compiled" are most often used by professionals in the field. I would bet good money that if a random subset of programmers were asked to choose "compiled" or "interpreted" when thinking of Perl, most would choose "interpreted". Not because of some theoretical argument over the nature of Perl, but because "compiled" usually invokes thoughts of "compiling", "linking", "object code" etc, while "interpreted" is taken to mean "write the code, try it". Right or wrong, that may be good to know when trying to determine if Perl is, truly, interpreted or in fact, compiled. You are going to run into many arguments on your quest.

Both. Perl5 compiles the source code into OPCODE objects, then interprets the OPCODE objects. Long answer follows.

From Wikipedia,

A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code).

Perl5 is a compiler. It takes Perl5 source code and produces of a graph of OPCODE objects.

$ perl -MO=Concise,-exec -E'for (1..3) { say "Hello, World!" }'
1  <0> enter 
2  <;> nextstate(main 48 -e:1) v:%,2048
3  <0> pushmark s
4  <$> const(IV 1) s
5  <$> const(IV 3) s
6  <$> gv(*_) s
7  <{> enteriter(next->c last->f redo->8) lKS/8
d  <0> iter s
e  <|> and(other->8) vK/1
8      <;> nextstate(main 47 -e:1) v:%,2048
9      <0> pushmark s
a      <$> const(PV "Hello, World!") s
b      <@> say vK
c      <0> unstack v
           goto d
f  <2> leaveloop vK/2
g  <@> leave[1 ref] vKP/REFC
-e syntax OK

However, the Perl5 compiler does not produce machine code. So how is the OPCODE graph executed? From Wikipedia, one definition for an interpreter is something that

explicitly executes stored precompiled code made by a compiler which is part of the interpreter system

This means the OPCODE graphs is interpreted.

Work was being done to provide the option to compile Perl5 to LLVM bytecode. This, in turn, can be jit compiled into machine code. This is the same approach Java uses.

Raku (Perl 6) has compatibility mode with Perl 5, so Perl 5 can be compiled to JVM and Parrot using Rakudo. I want LLVM for this!

Perl is an interpreted language. However, it does compile internally into p-code for efficiency.

From Wikipedia: "Perl is a high-level, general-purpose, interpreted, dynamic programming language". Perl 6 allows also for compilation (again, see Wikipedia).

Both. First, Perl 6 script is compiled to bytecode (and optimized). Then it is executed (however, you still need Perl interpreter for this). Bytecode is kind of executable code, which is independent from environment it runs on (the same bytecode can run on Unix enviroment on ARM processor, Windows system with x86 and Haiku on x64).

Perl 6 can be compiled to Parrot VM (Virtual Machine) bytecode. Parrot VM is used by Python and Ruby as well.

This is what makes Perl, Ruby and Python faster than PHP, which is just interpreted (can be compiled as well, but you need 3rd party components for this).

It's a VM that can also be compiled without the need of C. Its VM however is light years faster than Java so there really isn't anything that compares to it.

The bad - Its terrible in the same way C++ pushes to be a be all end all swiss army knife. In Perls case it removes the training wheels, safety and borders. For example in most OOP languages you must declare a class before you can use an object, in Perl there are no restrictions on types you can mix and match anything thereby turning anything into an object or an object into anything. The concept is confusing as hell if you already know OOP, the lack of restrictions is both powerful and a drawback in Perl. So whether the language is compiled or not isn't the issue so much as can you actually reason something effectively without braking the world. Another issue is that Perl is write only thus everything looks like gibberish once written and becomes difficult to dissect and even debug.

Most often interpreted but may be compiled also. about perl compiler