5 ms·

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 t

by 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.

by mahmud 17y ago

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.