New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing problem for "$a+++$b" #470
Comments
From merriam@world.std.comPardon if this isn't a bug; I'm a new Perl programmer. I run this in the perl debugger: $a = 1;$b = 2; The problem is that the statement $a+++$b is The correct response is an error. It is pain to find If you disagree, please explain it. No fair just Thank you, Charles Merriam Site configuration information for perl 5.00503: Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration: Locally applied patches: @INC for perl 5.00503: Environment for perl 5.00503: PATH=C:\PERL\BIN;C:\WINDOWS;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\VISUALCAFE\BIN;C:\VISUALCAFE\JAVA\BIN PERL_BADLANG (unset) |
From @tamiasOn Thu, Sep 02, 1999 at 11:41:21PM -0700, C M wrote:
The tokenizer/parser sees ++, so that's an auto-increment operator.
So don't generate Perl code like that. :) Easy enough to solve with Ambiguity is fun, it's what makes the Obfuscated Perl Contest interesting. Ronald |
From @TimToadyC M writes: Mere ambiguity is not sufficient for an error. The typical modern lexer A corollary to that is that, if you write $a+++$b without whitespace Larry |
From [Unknown Contact. See original ticket]Larry Wall writes:
Unfortunately, this rule is not applicable to Perl. perl -wle 'print 1..3' Given the above rule, one would expect "1.3". Ilya |
From @gbarrOn Fri, Sep 03, 1999 at 06:40:00PM -0400, Ilya Zakharevich wrote:
You would ? please explain. -- |
From [Unknown Contact. See original ticket]Graham Barr wrote:
Yeah, I would expect "13" if anything. 1 token hmm, print ".3" to filehandle "1.". Ok, switch to 'print (1..3)' and print (1. . 3) ==> "13" Now, how about 1...3? (First, figure out what you think perl really will |
From @tamiasOn Fri, Sep 03, 1999 at 06:40:00PM -0400, Ilya Zakharevich wrote:
Hmm, Larry said "longest operator token", not "longest token". 1 .. 3 has a longer operator token than 1. . 3 Ronald |
From [Unknown Contact. See original ticket]On Fri, Sep 03, 1999 at 07:30:51PM -0500, Graham Barr wrote:
Bad me, expecting 1. . 3 to be "1.3". Of course, it is "13". Ilya |
From [Unknown Contact. See original ticket]Ilya Zakharevich <ilya@math.ohio-state.edu> writes:
Why? '..' is longer than '.' so I would expect 1 .. 3 i.e. 1 2 3
|
From [Unknown Contact. See original ticket]Nick Ing-Simmons writes:
Tokens are processed left to right, thus the greediness is as in Ilya |
From @TimToadyIlya Zakharevich writes: Yes, Perl does an occasional lookahead when it figures the human And I did say "operator token" on purpose... Larry |
Migrated from rt.perl.org#1311 (status was 'resolved')
Searchable as RT1311$
The text was updated successfully, but these errors were encountered: