CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Intermediate: Re: [BillKSmith] flip flop operator with assignment operator: Edit Log



Laurent_R
Veteran / Moderator

Oct 1, 2014, 2:37 PM


Views: 4451
Re: [BillKSmith] flip flop operator with assignment operator

Hi Bill,
yes, I agree the OP code is puzzling. But removing the assignment as I suggested in the first place is the right thing to do and would solve the OP's problem. (As a side note, using a $a or $b variable is not a very good idea, because of their special meaning, that's why I changed it to $c in my code below.)

I tried to deparse your code but did not see anything suspicious. Deparsing further down to AST and opcodes might probably help, but I am not really able to understand the output.

I think it might be a precedence issue: because of the parens around the assignment, the conditional might really be interpreted as if the "if" condition was:


Code
if (($a=1)) {

i.e. in effect dropping the rest of the condition.

I tried to modify your code as follows (removing the parens around the assignment) :

Code
#!/usr/bin/perl   
use warnings;
use strict;

my $c;
while (<DATA>){
if ($c=1..4){
print $_;
}
}
__DATA__
a
b
c
d
e
f
g
...


And this way, it works fine:

Code
$ perl  flip_flop.pl 
a
b
c
d


So precedence might be a track to follow, but I am at best half-convinced, and I don't see very much how to further explore it.

The other (much less likely) possibility I was thinking of was that, perhaps, the peculiar syntax with the assignment within the parens was somehow forcing a list context to the ".." operator, so that it would act as a range operator and not as a flip-flop operator. A 1..4 range would obviously always be true, but I just can't see how this would possibly happen. I am just mentionning this as a very remote possibility, just in case someone has an idea based on that, but I don't believe this to be even mildly plausible at this point. And the additional problem is that I can't think about a test enabling us to prove or disprove that.

Well, not sure this post is very useful, but at least a couple of ideas to ponder on.


(This post was edited by Laurent_R on Oct 1, 2014, 2:42 PM)


Edit Log:
Post edited by Laurent_R (Veteran) on Oct 1, 2014, 2:42 PM


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives