develooper Front page | perl.perl5.porters | Postings from February 2020

Re: chained comparisons

Thread Previous | Thread Next
From:
demerphq
Date:
February 6, 2020 02:01
Subject:
Re: chained comparisons
Message ID:
CANgJU+UxY8NdqT+eyXzVuvxg5acPd3pG9UkQFmFmwnGt=_VL8w@mail.gmail.com
On Wed, 5 Feb 2020 at 08:50, Zefram via perl5-porters <
perl5-porters@perl.org> wrote:

> Branch zefram/cmpchain at <git://river.fysh.org/zefram/perl.git> may be
> of some interest.
>

BTW, it was pointed out that this breaks some legal code, albeit weirdo
stuff, for instance:

sub foo {42} foo < $y > /bar/g

Which some might argue should mean it needs a feature flag. That would make
me sad, so im hopeful the community can decide that weirdo code like this
isnt a concern, but knowing our slavish fetish towards back compat I was
thinking of another option.

If we stipulate that the operators must be of the same "inequality"nes for
the full expression this problem goes away.

By that I mean,

if (1 < $x < $y < 10) { ..}
if (10 > $y > $x > 1) { ..}

would be legal but

if (1 < $x > $y ) would not be, so it would have to be written

if (1 < $y < $x)

Thus you could chain <, <= le lt and == and eq,
and you could chain >, >= ge gt and == and eq, but you could not mix the
two sets with the exception of equality operators.

IMO this would actually be a good thing, as it would mean that people using
this feature would have to do it the way mathematicians would normally do
it.

Id even be fine with saying "you can only chain <, <=, le, lt and ==", that
is only support half the ops, which would also resolve the conflict with
<>. But I can imagine some saying its weird that it isn't "symmetric"

Curious what your thoughts on this.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About