> Wait, so Perl 5 doesn't interpret every statement as it parses it?
I'm sorry, was anyone seriously suggesting this? Don't most production-grade interpreters still parse the program before executing it?
The article seems to be premised on a very strange definition of compilation. It's suggesting that building a parse tree and then executing it is compilation. Maybe I missed something, but compilation as an activity generally has a translation flavour about it. This really doesn't. There is no "target" language. There is a data structure that stores a representation of the source code, and then some program transformations (within the same source language semantics). It then executes the original program using the representation stored in this data structure. Sure, it's not like it's executing as it is parsing, but there is no "code generation" here. If you dumped out the data structure storing what is essentially a parse tree, you would basically get the original source program (+/- some syntax).
We're still in the same source language. No "compilation" has happened. Am I missing something? Is there a reason the author is claiming that there are distinct "compile" and "execute" phases when he appears to be describing a fairly run-of-the-mill interpreter implementation?
For example (in some pseudo-code):
a = x + 10
Perl 5 builds a tree from this (e.g. Assign(a, Add(x, 10))) and then executes it. Even the traversal of the tree proceeds according to the results of executing the program up to that point.
If we were to take the tree I generated above, we could get the exact same program out of it. I agree that this would be difficult with Perl - not because the parse tree is substantially different from the program text, but rather because it is ambiguous.
We could also target some arbitrary language. This is not the case in Perl, because it can't. The tree has absolutely no meaning other than that given to it through execution. It's not even an abstract syntax tree - it's just a parse tree! The semantics of the tree are exactly the same as the Perl code from which the tree was derived. And I don't mean "semantically equivalent", I mean, "identical by definition", because the source only has meaning because the tree is executed.
In a compiler setting, we can take an arbitrary (valid) program and give its meaning in terms of the target language. An abstract syntax tree has its own semantics, into which the original program text (or parse tree) is translated. The AST is given a semantics by a code generator, which translates constructs in the AST into constructs in the target language (which has yet another set of semantics).
If the parse tree is never translated to another form, then I think it's fair to say Perl is interpreted, not compiled.
I admit that there's a continuum between "pure compilation" and "pure interpretation", but when you have people claiming that Java is a compiled language, the lines are awfully blurry.
I take "interpreted" in its purest form as "parses and executes a line at a time", which is why I mentioned REPLs in the article.
In Perl 5 parlance, "compile time" is when parsing happens. "Runtime" is when execution happens.
I think you've taken a technically accurate comment and then answered a completely different point.
In the general case, Perl 5 subroutines have well-defined arities: they consume as many arguments as possible, either delimited by parentheses or the statically-unambiguous end of an expression.
In the special case of prototyped subroutines, the parser knows their arities as soon as it encounters their declarations.
None of this has any connection to the claim that "it's necessary to execute the subroutine to discover just how many [tokens] it will consume." If that were true, perl -c would not work.
Think of any language family and you could classify them in some fashion. They fit some sort of a theoretical model you could reason about. Perl5 is .. well, whatever Larry knew how to do. However, it does a good job of not sucking for Unix administration; whenever I need it, about once every 6 months, Perl saves me from the trouble of launching splitvt and reading the manuals of several unix utilities. It's like a John Waters or a Roger Corman* movie, so bad it's good.
* not to be confused with Richard Waters and the other Roger Corman, both fine Lispers ;-)
And yes, that is as bizarre as it seems.
I think this article is pretty disingenuous. It's trying to pretend that there is something really complicated going on here (e.g. "That's one way in which Perl 5 differs from other language implementations; it manages the artifacts of compilation itself"), when really, it's actually just poor design layered upon poor design.
> Perl 5's execution model isn't quite the same as a traditional compiler (whatever that means) and it's definitely not the same as the traditional notion of an interpreter. There are two distinct phases of execution of a Perl 5 program: compile time and runtime. You must understand the difference to take full advantage of Perl 5.
This is true, but only if you don't really understand what a traditional compiler or a traditional interpreter might entail, given that Perl is basically doing what Python, Ruby, Matlab and any number of other language implementations do, it's just doing it in such a way that it has to account for flaws in the design of the language.
Grammar modifications in BEGIN blocks make the parsing process a little different from many other languages with which I believe readers are familiar.
I'm not even saying there is anything wrong with this, I'm just arguing that the way you have described the "compilation" process in Perl is basically a textbook description of an interpreter that relies on some runtime information in order to execute the program.
e.g. I enjoy marmite but I don't _love_ it
Also consider the following:
- that most people dislike it the first time (i.e. it's an acquired taste)
- most first timers are introduced to it by someone who "loves" it
These make all acquired tastes seem polarising even if they really aren't.
... although maybe that's what you were trying to say about perl.
for eg. I hated beer first time I tasted it... but now I love it ;-)