4 ms·

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual

by andreyf 12y ago

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter, but it's definitely interpreting byte code, not the source directly. This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g. whatever / 25 ; # / ; die "this dies!";

haberman 12y ago
> This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html http://perldoc.perl.org/5.8.9/perlcompile.html) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to produce a parse tree prior to running the program. I could not get your code sample to die based on the type/value of "whatever" -- can you?
- scott_s 12y ago
  Apparently, Perl is that crazy. See https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531 Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.
  - haberman 12y ago
    > Basically, you can't always parse a Perl program without running it. That is true, but what the grandparent said is not: https://news.ycombinator.com/item?id=8626454 https://news.ycombinator.com/item?id=8626454 To expand on this, I think a succinct way of summarizing the issue is: you might have to run BEGIN blocks in Perl to parse the non-BEGIN-block part of the program. The canonical example of this is: BEGIN { if(arbitrary_function()) { eval "sub whatever() { }; 1" or die $@; } else { eval "sub whatever { }; 1" or die $@; } } # The parsing of this line depends on the result of arbitrary_function() whatever / 25 ; # / ; die "this dies!"; arbitrary_function() can be anything, so the only way to parse the rest of the program is to actually run arbitrary_function().
- deleted 12y ago
  [deleted]
  - haberman 12y ago
    I am aware of this result. However, that differs from what GP said in one important way. Grandparent said "This is very different from Perl, where a line of code isn't parseable until you know the values of the variables." If that were true, it would imply that you could have a loop whose body is parsed differently on every iteration. It would imply that the parser runs inline with the interpreter. Neither of those things are true. What your link says is that the parsing can vary based on whether or not a subroutine prototype with appropriate arity was previously defined. That is a very different thing. A statement in a loop could be parsed differently depending on what was defined before it, but that parse doesn't change just because a subroutine is defined later, I'm pretty sure. Yes, this means Perl's parsing is undecideable, because you can conditionally define a subroutine (this might be limited to BEGIN blocks; I'm not sure). But that's not the same as saying the parse varies based on the "values of the variables."
- deleted 12y ago
  [deleted]
twoodfin 12y ago
FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter... Because CPython implements its virtual machine with an interpreter, without the option of, say, a JIT compiler.
Moto7451 12y ago
Did you try running that? [13:06:36] ~$perl -e 'whatever / 25 ; die "this dies!";' this dies! at -e line 1. [13:06:36] ~$ [13:06:38] ~$perl -e "use strict; use warnings; whatever / 25 ; die "this dies!";" Useless use of division (/) in void context at -e line 1. Bareword "whatever" not allowed while "strict subs" in use at -e line 1. Execution of -e aborted due to compilation errors. [13:06:38] ~$ After removing the comment the former parses just fine and died with "this dies!". The latter parsed and found a syntax error.

by andreyf 12y ago

haberman 12y ago

> This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html http://perldoc.perl.org/5.8.9/perlcompile.html) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to produce a parse tree prior to running the program. I could not get your code sample to die based on the type/value of "whatever" -- can you?

scott_s 12y ago
Apparently, Perl is that crazy. See https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531 Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.
- haberman 12y ago
  > Basically, you can't always parse a Perl program without running it. That is true, but what the grandparent said is not: https://news.ycombinator.com/item?id=8626454 https://news.ycombinator.com/item?id=8626454 To expand on this, I think a succinct way of summarizing the issue is: you might have to run BEGIN blocks in Perl to parse the non-BEGIN-block part of the program. The canonical example of this is: BEGIN { if(arbitrary_function()) { eval "sub whatever() { }; 1" or die $@; } else { eval "sub whatever { }; 1" or die $@; } } # The parsing of this line depends on the result of arbitrary_function() whatever / 25 ; # / ; die "this dies!"; arbitrary_function() can be anything, so the only way to parse the rest of the program is to actually run arbitrary_function().
deleted 12y ago
[deleted]
- haberman 12y ago
  I am aware of this result. However, that differs from what GP said in one important way. Grandparent said "This is very different from Perl, where a line of code isn't parseable until you know the values of the variables." If that were true, it would imply that you could have a loop whose body is parsed differently on every iteration. It would imply that the parser runs inline with the interpreter. Neither of those things are true. What your link says is that the parsing can vary based on whether or not a subroutine prototype with appropriate arity was previously defined. That is a very different thing. A statement in a loop could be parsed differently depending on what was defined before it, but that parse doesn't change just because a subroutine is defined later, I'm pretty sure. Yes, this means Perl's parsing is undecideable, because you can conditionally define a subroutine (this might be limited to BEGIN blocks; I'm not sure). But that's not the same as saying the parse varies based on the "values of the variables."
deleted 12y ago
[deleted]

twoodfin 12y ago

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter... Because CPython implements its virtual machine with an interpreter, without the option of, say, a JIT compiler.

Moto7451 12y ago

Did you try running that? [13:06:36] ~$perl -e 'whatever / 25 ; die "this dies!";' this dies! at -e line 1. [13:06:36] ~$ [13:06:38] ~$perl -e "use strict; use warnings; whatever / 25 ; die "this dies!";" Useless use of division (/) in void context at -e line 1. Bareword "whatever" not allowed while "strict subs" in use at -e line 1. Execution of -e aborted due to compilation errors. [13:06:38] ~$ After removing the comment the former parses just fine and died with "this dies!". The latter parsed and found a syntax error.