On Nov 12, 2016 8:21 AM, "David Walker" <dave+...@mudsite.com> wrote:
>
> On Sat, Nov 12, 2016 at 3:08 AM Lauri Kenttä <lauri.ken...@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

Reply via email to