Is Perl a compiled or an interpreted programming language?
Solution 1
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.
Solution 2
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.
Solution 3
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.
Solution 4
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!
Related videos on Youtube
Comments
-
Mr. L over 1 year
Is Perl compiled or interpreted?
-
Mr. L about 13 yearsso does your first sentence is only correct regarding Perl6? Does it make Perl5 interpreted only language?
-
Dr McKay about 13 yearsThought of Perl 6. Sorry, will fix it.
-
Prof. Falken about 13 yearsI don't think what is usually called p-code ( en.wikipedia.org/wiki/P-code_machine ) can be compared to what Perl is usually parsed into.
-
Mr. L about 13 yearscan you define 'most often' :)
-
Shamit Verma about 13 yearsp-code is like ByteCode. P-Code-Machine is like JVM. Actual structure of translated state depends on Perl implementation. BTW, there is an implementation of Perl for JVM too : javainc.com/projects/jperl similarly there are implementations that use ByteCode of CLR.
-
Prof. Falken about 13 yearsAh, I see now about the ByteCode. Thanks. Interesting about jperl. But it seems it just interprets Perl? It would have been cooler (but harder I guess) if it compiled Perl to class files.
-
tchrist about 13 yearsThis isn’t really accurate. If Perl isn’t compiled, where does the parse tree come out of? You can’t get a parse tree without a parser — which is all compiling is. Perhaps if the question had talked about code-generation of native machine language, your answer would fit better. But it didn’t, for code generation is quite a different thing from compilation.
-
Prof. Falken about 13 yearsI retract that, seems it is compiled to some sort of bytecode, although official support for writing bytecode to files was removed at 5.10.
-
Dr McKay about 13 yearsI wouldn't really call it a bytecode. These text may explain it: socialtext.net/perl5/optree_guts perldoc.perl.org/perlguts.html#Compiled-code
-
ikegami about 13 yearsPerl5 produces a graph of opcode objects. What it produces is not p-code as it is neither portable nor instructions for some virtual machine.
-
ikegami about 13 years@Amigable Clark Kant, You are refering to
perlcc
.perlcc
attempted to serialize Perl5's opcodes. It was never part of the process of executing Perl5 code. -
tchrist about 13 yearsDon’t use the past tense when describing
perlcc
. It was simply de-coupled from the core. It was not retired. There’s been a lot of work done on it. -
tchrist about 13 yearsProfessionals use the definition given in this answer. Plebes tend to use something murkier.
-
ikegami about 13 years@tchrist, I would not expect a professional to discuss languages in terms of whether they are interpreted or compiled.
-
ikegami about 13 years@tchrist, I was under the impression that it didn't even run against newer version of Perl. Are you saying I remember incorrectly (entirely possible) or that it isn't the case anymore? (PS - I don't get notified if you don't tag me.)
-
Prof. Falken over 10 years@tchrist, OTOH, then almost all languages are compiled, because almost all of them have parsers.
-
Kaz about 10 years@tchrist No, parsing to make a syntax tree is not compiling. If you dsiagree, then you must believe that there doesn't exist any interpreted Lisp, because Lisps read stuff like
(let ((a b)) c)
and turn it into a tree in memory. However, there is a difference between running that statement by walking the tree, and generating code. -
Kaz about 10 years@ikegami I would. There are semantic differences. Programs in interpreted languages can do things which are impossible to compile. If such use is predominant among the users of a language, then it is strictly an interpreted language. For instance, an interpreted language can allow user-defined programs to extend the interpreter with custom interpretation routines. No compiler can determine what these routines do (or whether they even halt for a given set of inputs) to be able to emit the equivalent code.
-
Kaz about 10 yearsCompiling means we generate something which is self-contained: it does not require help from an interpreter's run-time support for doing things like creating and resolving local variables, calling functions, or checking types. These things are done by machine language. Or at least a pseudo-machine language which has nothing to do with the specific interpreter for that specific language. When your "machine language" has a LAMBDA opcode to capture a lexical environment and make a function, that's not really compiling; it's quasi-compiling.
-
Kaz about 10 years@ikegami Hmm, try googling for "fexpr"; that might be better.
-
Kaz about 10 years@ikegami The issue is not whether the body of the fexpr is compiled or not, but whether the actions of the fexpr can be replaced by code generation, so the fexpr is no longer used. I.e. the compiler looks at the code and sees, "Aha, this is calling a loop fexpr. Judging by the code of that fexpr, it's a loop. So I will just generate a loop that doesn't call the fexpr any more". If you can compile user-defined fexprs in the language itself, that makes fexprs unnecessary. Why optimize interpreters, when you're already compiling?
-
ikegami about 10 years@Kaz, Sorry, I have no idea what you just said, and more importantly, I still don't see how fexprs lead professionals to discuss languages in term of whether they are interpreted or compiled.
-
Hunan Rostomyan over 8 yearsVery helpful. Thanks!
-
Dylan Richards over 7 yearsThank you for the only straightforward answer on the damn page.
-
ikegami about 7 years@Prof. Falken, Re "then almost all languages are compiled", Of course they are. It would be silly to write a fully interpreted programming language. Only shell-type languages are interpreted now.
-
ikegami about 7 yearsRe "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", huh? By that definition, Perl 5 is compiled. It produces an assembler program composed of high-level opcodes. /// Re "It does not output any bytecode, assembly or real machine code usually associated with compilers", It does; it just doesn't bother writing it to disk. There was a tool to do so, but it wasn't maintained. So by both of your definitions, Perl5 is compiled
-
Prof. Falken about 7 years@ikegami Well, at least PicoLisp is interpreted IIRC. I did not know that Perl 5 also uses bytecode. EDIT - Also look at my other paragraphs - I am not actually trying to argue one way or another. I maybe should rewrite the answer a bit, but not today. What I am roughly going for is an expose over arguments why Perl 5 may or may not be called a compiled language. In any case, Perl (5) seems to be a language that somehow is hard to get a consensus on. FORTRAN - compiled. PicoLisp - interpreted. Perl? Lots of arguing...
-
ikegami about 7 yearsRe "Perl (5) seems to be a language that somehow is hard to get a consensus on.", Perl "explicitly executes stored precompiled code made by a compiler which is part of the interpreter system". That's a definition of an interpreter, so Perl is an interpreter that includes a compiler. The lack of concensus comes from people incorrectly assuming it has to be one or the other.
-
matanster about 6 yearsWouldn't the same be said of any interpreted language, python as a case in point?