Re: [RFC] Interval Comparison

On Nov 12, 2016 8:21 AM, "David Walker" <dave+php@mudsite.com> wrote: > > On Sat, Nov 12, 2016 at 3:08 AM Lauri Kenttä <lauri.kentta@gmail.com> wrote: > > > On 2016-11-11 19:03, David Walker wrote: > > > > > > I took a quick stab at implementing, and had something working for > > > constant expressions, but handling something akin to: > > > > > > $a = 2; > > > if (1 < $a++ < 3) { > > > ... > > > } > > > > > > Is a bit awkward in our expansions of : if (1 < $a++ && $a++ < 3). > > > Seems as if when processing the chain here, you'd need to see if the > > > left node has a child, and somehow ensure you get the evaluated value > > > somehow, to override the "left" node. So logically expansion of the > > > above would be if (1 < $a++ && 3 < 3). I think the same would have > > > too somehow handle (either by syntax error or something) that if a > > > non-numeric value creeps into a binary-op-compare we error like: if > > > (1 < (2==3) < 3). > > > > > > Just some food for thought > > > -- > > > Dave > > > > I don't see how you would ”logically” get 3 < 3. The very point of > > chaining is that each expression is evaluated only once, so the > > expression will have the same value in both of the comparisons. So if > > the first part is 1<2, then the other must be 2<3 (and not 3<3). > > > > An expression like a < b < c < d can be currently implemented with > > temporary variables like this: > > a < ($tmp1 = b) && $tmp1 < ($tmp2 = c) && $tmp2 < d > > > > That's was the intent in the question I tried to raise with the > post-increment, as you write $tmp1 = b, to my example > $tmp1 = $a++: > > Should > $a = 1; > var_dump(1 < $a++ < 3); > > (expanded into numbers) be evaluated as: > 1 < 2 && 2 < 3 - True > or > 1 < 2 && 3 < 3 - False > > I could see the case for either, although, I would probably prefer the > latter, as that's what's apparent today, example with > > ``` > $a = 0; > var_dump($a < 1); > var_dump(++$a < 1); > ``` > > Would print out true, false. > > Sorry I wasn't overly clear in my statement. > -- > Dave +1 on the usefulness of this idea. I've always wondered why more parsers don't already support this. --Kris