Mailing List Archive

On 07.02.24 12:39, Windl, Ulrich wrote:
> Here is a problem:
>
> I have a selftest that goes like “if ($obj->method()) { fine() } else
> {bad() }” I id coverd that depending on the version of some external
> module, the logic may be inverted, because the test should have failed
> actually if the module weren’t broken
>
> So to fix, I added a variable Boolean $broken, and the logic would be
> “if ($broken && $obj->method() || $broken && ! $obj->method()) { fine()
> } else {bad() }”, obviously an XOR. However as I don’t really know
> whether the method returns a number, I cannot use the ^ (bitwise)
> operator, and abviously there is no ^^ logical operator.

Logical XOR is just not-equals on booleans. Your proposed A ^^ B can be
written as (!A) != (!B) today.

On 2024-02-08 7:40 p.m., Lukas Mai wrote:
> On 07.02.24 12:39, Windl, Ulrich wrote:
>> Here is a problem:
>>
>> I have a selftest that goes like “if ($obj->method()) { fine() } else {bad()
>> }” I id coverd that depending on the version of some external module, the
>> logic may be inverted, because the test should have failed actually if the
>> module weren’t broken
>>
>> So to fix, I added a variable Boolean $broken, and the logic would be “if
>> ($broken && $obj->method() || $broken && ! $obj->method()) { fine() } else
>> {bad() }”, obviously an XOR. However as I don’t really know whether the method
>> returns a number, I cannot use the ^ (bitwise) operator, and abviously there
>> is no ^^ logical operator.
>
> Logical XOR is just not-equals on booleans. Your proposed A ^^ B can be written
> as (!A) != (!B) today.

I agree xor is just not-equals on booleans, as xnor is equals on booleans.

I see 2 main things the explicit operator would gain us:

1. It would tersely cast the arguments as booleans, bringing parity with ne
doing it to strings and != doing it to numbers.

2. It would bring design parity with the set of bitwise operators, for what
that's worth.

But in the absence of this, an explicit cast plus !+ isn't a terrible option.

(In some ways supporting xor as a distinct operator is kind of arbitrary
considering even in languages having it they are typically omitting most of the
other dyadic boolean operators anyway, of which there are 10 total.)

-- Darren Duncan

On Wed, 7 Feb 2024 11:39:57 +0000
"Windl, Ulrich" <u.windl@ukr.de> wrote:

> Here is a problem:
> I have a selftest that goes like "if ($obj->method()) { fine() } else {bad() }" I id coverd that depending on the version of some external module, the logic may be inverted, because the test should have failed actually if the module weren't broken
> So to fix, I added a variable Boolean $broken, and the logic would be "if ($broken && $obj->method() || $broken && ! $obj->method()) { fine() } else {bad() }", obviously an XOR. However as I don't really know whether the method returns a number, I cannot use the ^ (bitwise) operator, and abviously there is no ^^ logical operator.
>
> Here is the syntax that I'm proposing:
> if (!($broken ^^ $obj->method())) { fine() } else {bad() }" (if I got the logic right)
>
> Here are the benefits of this:
> With & and &&, | and ||, (~ and !) that just seems logical to have ^and ^^.
>
> Here are potential problems:
> I don't see any potential problems with that.

Perl does have a logical xor operator, it's spelled "xor":

> perl -Mwarnings -E 'if(undef ^ 1) { say 1 }'
Use of uninitialized value in numeric bitwise xor (^) at -e line 1.
1

> perl -Mwarnings -E 'if(undef xor 1) { say 1 }'
1

Hi!

OK, I didn't know that. Actually I had implemented my own XOR() in the meantime. Still ^^ would make sense for consistency IMHO

Ulrich

-----Original Message-----
From: Tomasz Konojacki <me@xenu.pl>
Sent: Friday, February 9, 2024 6:27 AM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: perl5-porters@perl.org
Subject: [EXT] Re: Why doesn't Perl have the ^^ operator?

On Wed, 7 Feb 2024 11:39:57 +0000
"Windl, Ulrich" <u.windl@ukr.de> wrote:

> Here is a problem:
> I have a selftest that goes like "if ($obj->method()) { fine() } else {bad() }" I id coverd that depending on the version of some external module, the logic may be inverted, because the test should have failed actually if the module weren't broken
> So to fix, I added a variable Boolean $broken, and the logic would be "if ($broken && $obj->method() || $broken && ! $obj->method()) { fine() } else {bad() }", obviously an XOR. However as I don't really know whether the method returns a number, I cannot use the ^ (bitwise) operator, and abviously there is no ^^ logical operator.
>
> Here is the syntax that I'm proposing:
> if (!($broken ^^ $obj->method())) { fine() } else {bad() }" (if I got the logic right)
>
> Here are the benefits of this:
> With & and &&, | and ||, (~ and !) that just seems logical to have ^and ^^.
>
> Here are potential problems:
> I don't see any potential problems with that.

Perl does have a logical xor operator, it's spelled "xor":

> perl -Mwarnings -E 'if(undef ^ 1) { say 1 }'
Use of uninitialized value in numeric bitwise xor (^) at -e line 1.
1

> perl -Mwarnings -E 'if(undef xor 1) { say 1 }'
1

Tomasz Konojacki:

> Perl does have a logical xor operator, it's spelled "xor":

Using Lukas's equivalence:

perl -E 'say !shift != !shift' 0 1
1

Using the existing xor operator:

perl -E 'say shift xor shift' 0 1
0

OK, that can be addressed with parens. But for && and || you don't need
the parens, so it's awkward that the only exclusive-or operator has a
difference precedence.

It would make sense for Perl to have ^^ but not the super-low-
precedence xor version. Low-precedence or and and are useful for joining
commands together conditionally, where the result of the first command
determines whether the second is run. With xor that's nonsense, because
both operands have to be evaluated anyway.

(Obviously I'm not suggesting removing xor, because it does exist and it
isn't causing any harm. But it's hard to see how it's useful with low
precedence.)

I don't exclusive-or often, but when I do, I've often wished for ^^.
Given |, &, ^, ||, and &&, it isn't like ^^ could ever really be used
for something else.

So I'd welcome ^^ being added, if somebody has the inclination to code
it. But it's hardly a priority compared to other things busy Porters are
currently working on.

Smylers

On 2024-02-09 4:24 a.m., Smylers via perl5-porters wrote:
> It would make sense for Perl to have ^^ but not the super-low-
> precedence xor version. Low-precedence or and and are useful for joining
> commands together conditionally, where the result of the first command
> determines whether the second is run. With xor that's nonsense, because
> both operands have to be evaluated anyway.
>
> (Obviously I'm not suggesting removing xor, because it does exist and it
> isn't causing any harm. But it's hard to see how it's useful with low
> precedence.)

From a design perspective, I disagree with you. There should be full parity
where each logical operator has a low and high precedence version. The existing
lower priority xor is no less valuable than the proposed higher priority
symbolic version. -- Darren Duncan

This comment might not help anything but
this is exactly the kind of thing a Perl-powerful macro system would be
good for.

OTOH, having to declare it before use, like an experimental feature,
wouldn't scratch the
itch of "this one is missing, add it please" which seems entirely valid.

I say, add it because adding it shouldn't be that tricky as we've already
got || and && and also
adding it won't hurt anything.

On Fri, Feb 9, 2024 at 2:19?PM Darren Duncan <darren@darrenduncan.net>
wrote:

> From a design perspective, I disagree with you. There should be full
> parity
> where each logical operator has a low and high precedence version. The
> existing
> lower priority xor is no less valuable than the proposed higher priority
> symbolic version. -- Darren Duncan
>


--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

I don't think there's any particular design or reason why we don't have
a ^^ operator, we've just never really needed it or got around to
adding one.

It's unlikely to get in for 5.40, but if anyone feels strongly that we
should have such an operator, make a branch and add some tests and
docs, and I can write the actual code to do it. Then we'll be in a
position to think about merging it or not.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Op 13-02-2024 om 17:02 schreef Paul "LeoNerd" Evans:
> I don't think there's any particular design or reason why we don't have
> a ^^ operator, we've just never really needed it or got around to
> adding one.
>
> It's unlikely to get in for 5.40, but if anyone feels strongly that we
> should have such an operator, make a branch and add some tests and
> docs, and I can write the actual code to do it. Then we'll be in a
> position to think about merging it or not.
>

Tests done, docs still todo, but when done, can I just push that branch
or do I need to get some permissions first?


M4

On 2/13/24 17:06, Martijn Lievaart via perl5-porters wrote:
> Op 13-02-2024 om 17:02 schreef Paul "LeoNerd" Evans:
>> I don't think there's any particular design or reason why we don't have
>> a ^^ operator, we've just never really needed it or got around to
>> adding one.
>>
>> It's unlikely to get in for 5.40, but if anyone feels strongly that we
>> should have such an operator, make a branch and add some tests and
>> docs, and I can write the actual code to do it. Then we'll be in a
>> position to think about merging it or not.
>>
>
> Tests done, docs still todo, but when done, can I just push that branch
> or do I need to get some permissions first?
>

Best to push a branch to your own GH repository and make a pull request.

On Tue, 13 Feb 2024 23:06:32 +0100
Martijn Lievaart via perl5-porters <perl5-porters@perl.org> wrote:

> Op 13-02-2024 om 17:02 schreef Paul "LeoNerd" Evans:
> > I don't think there's any particular design or reason why we don't
> > have a ^^ operator, we've just never really needed it or got around
> > to adding one.
> >
> > It's unlikely to get in for 5.40, but if anyone feels strongly that
> > we should have such an operator, make a branch and add some tests
> > and docs, and I can write the actual code to do it. Then we'll be
> > in a position to think about merging it or not.
> >
>
> Tests done, docs still todo, but when done, can I just push that
> branch or do I need to get some permissions first?

Tests and docs were provided, and now I have written an actual
implementation.

Draft PR here:

https://github.com/Perl/perl5/pull/21996

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/