5 ms·

How a Perl 5 Program Works

34 points by draegtun 17y ago

known 17y ago
I love Perl.
- draegtun 17y ago
  Perl seems to be the Marmite of the programming languages ;-) ref: http://www.marmite.com/ http://www.marmite.com/
  - sharkbrainguy 17y ago
    That "people either love or hate x" is almost always a myth created by vocal minorities. 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.
    - draegtun 17y ago
      re: "acquired taste" - I totally agree. for eg. I hated beer first time I tasted it... but now I love it ;-)
- mahmud 17y ago
  Read that article and you wouldn't love it as much. Of all the high-level languages whose compilation and evaluation model I am familiar with, Perl5's has got to be the worst. I can't even classify it; the intermediate representation and evalution is not stack based or register based, it's not threaded interpretation, not metacircular, it's not graph reduction or term rewriting, not even "string" based (a la the weird 3rd implementation of Scheme in Kent Dybvig's PhD thesis.) So what on bloody earth is Perl5? At least Basic has the decency is to be stupid, both in essence and appearance. 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 ;-)
  - gdp 17y ago
    It's building a parse tree, and then attempting to use the unambiguous bits like an abstract syntax tree, presumably to side-step the statically unresolvable ambiguity mentioned in the previous article. 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.
    - chromatic 17y ago
      The much paraded statically unresolvable ambiguity does not apply when the Perl 5 parser parses Perl 5 code for reasons explained in the article. The parse tree produced is unambiguous. Grammar modifications in BEGIN blocks make the parsing process a little different from many other languages with which I believe readers are familiar.
      - gdp 17y ago
        Sure, the generation of a parse tree is unambiguous, but the traversal order of that tree is not statically determinable. 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.
draegtun 17y ago
See also HN discussion on original PerlMonks post that started all this: http://news.ycombinator.com/item?id=761103 http://news.ycombinator.com/item?id=761103
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 ago
  How 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 ago
    It'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).
draegtun 17y ago
Also see Stackoverflow question on this topic: http://stackoverflow.com/questions/1280594/can-perl-be-statically-parsed http://stackoverflow.com/questions/1280594/can-perl-be-stati...

34 points by draegtun 17y ago

known 17y ago

I love Perl.

draegtun 17y ago
Perl seems to be the Marmite of the programming languages ;-) ref: http://www.marmite.com/ http://www.marmite.com/
- sharkbrainguy 17y ago
  That "people either love or hate x" is almost always a myth created by vocal minorities. 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.
  - draegtun 17y ago
    re: "acquired taste" - I totally agree. for eg. I hated beer first time I tasted it... but now I love it ;-)
mahmud 17y ago
Read that article and you wouldn't love it as much. Of all the high-level languages whose compilation and evaluation model I am familiar with, Perl5's has got to be the worst. I can't even classify it; the intermediate representation and evalution is not stack based or register based, it's not threaded interpretation, not metacircular, it's not graph reduction or term rewriting, not even "string" based (a la the weird 3rd implementation of Scheme in Kent Dybvig's PhD thesis.) So what on bloody earth is Perl5? At least Basic has the decency is to be stupid, both in essence and appearance. 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 ;-)
- gdp 17y ago
  It's building a parse tree, and then attempting to use the unambiguous bits like an abstract syntax tree, presumably to side-step the statically unresolvable ambiguity mentioned in the previous article. 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.
  - chromatic 17y ago
    The much paraded statically unresolvable ambiguity does not apply when the Perl 5 parser parses Perl 5 code for reasons explained in the article. The parse tree produced is unambiguous. Grammar modifications in BEGIN blocks make the parsing process a little different from many other languages with which I believe readers are familiar.
    - gdp 17y ago
      Sure, the generation of a parse tree is unambiguous, but the traversal order of that tree is not statically determinable. 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.

draegtun 17y ago

See also HN discussion on original PerlMonks post that started all this: http://news.ycombinator.com/item?id=761103 http://news.ycombinator.com/item?id=761103

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 ago
How 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 ago
  It'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).

draegtun 17y ago

Also see Stackoverflow question on this topic: http://stackoverflow.com/questions/1280594/can-perl-be-statically-parsed http://stackoverflow.com/questions/1280594/can-perl-be-stati...