Oct 1, 2014, 2:37 PM
Post #7 of 7
Re: [BillKSmith] flip flop operator with assignment operator
[In reply to]
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:
i.e. in effect dropping the rest of the condition.
I tried to modify your code as follows (removing the parens around the assignment) :
And this way, it works fine:
$ perl flip_flop.pl
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)