4 ms·
From the "questions" section at the bottom of the article: > Wait, so Perl 5 doesn't interpret every statement as it parses it? I'm sorry, was anyone seriousl
by gdp 17y ago
From the "questions" section at the bottom of the article:
> 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?
- phaylon 17y agoHow is the transformation into bytecode before execution not a translation? Yes, the bytecode format is perl-specific, but you can't easily get at the real original source code again.
- gdp 17y agoIt's not bytecode! There is no bytecode involved at all. It's just a representation of the source program text. 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).
- calcnerd256 17y agoSomeone should rewrite Perl in Lisp.
- phaylon 17y agoI'm sorry if I was unclear, but I still don't see any problem with this being called a compilation of one format into another.
- scott_s 17y agogdp's objection to calling this compilation, which I share, is that there is only one form.
- phaylon 17y agoNo, there isn't. There is the source, and there is the prepared and executed optree. The building of this is in Perl called the compile time phase. Which makes sense to me. I can't see how the source file and the parsed optree can be the same form. They do the same things, yes. But most source code and compiled forms have that in common.
- 17y ago
- chromatic 17y agoDid you read the LTU link? Someone seriously suggested that Perl 5 obviously works by reparsing code at run time. 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.
- gdp 17y agoOh, that would be a very strange interpretation of interpretation. I'm not sure what you mean by "reparsing code at runtime". Given that there isn't really a "compile time" in a perl-like setting, when are you proposing the parsing happens?
- chromatic 17y agoRead the link. The poster suggested that Perl 5 subroutines take as an invisible argument the remaining source code (presumably from the end of the declaration of that sub to the end of the file) of the program so that they could reparse the remaining code when the subs evaluate to a known value. In Perl 5 parlance, "compile time" is when parsing happens. "Runtime" is when execution happens.
- gdp 17y agoOh, I just read the comment you're referring to, and I think you've completely misinterpreted the commenter. The use of "program text" is used in a fairly precise way to mean "the tokens unconsumed up to this point in the execution", which appears to be what you asserted in your reply. Of course, given that the parse tree is just a structured representation of the program text, with no pre-determined traversal order, is it not true that the parser needs the context resulting from having evaluated part of the tree in order to decide how to proceed in evaluating the rest of it? I think you've taken a technically accurate comment and then answered a completely different point.
- 17y ago