Introduce string-specific bitwise ops

[p5pRT]

Migrated from rt.perl.org#123466 (status was 'resolved')

Searchable as RT123466$

[p5pRT]

From @cpansprout

In order to fix the problems with & | ^ ~ having unpredictable behaviour based on the operands’ internal flags, I propose we make them number-specific and introduce new string-specific ops, called band, bor, bxor and bnot. These would be enabled under a new feature.pm feature. Outside of the feature feature, they would behave erratically as before.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Sat Dec 20 17​:58​:39 2014, sprout wrote​:

In order to fix the problems with & | ^ ~ having unpredictable
behaviour based on the operands’ internal flags, I propose we make
them number-specific and introduce new string-specific ops, called
band, bor, bxor and bnot. These would be enabled under a new
feature.pm feature. Outside of the feature feature, they would behave
erratically as before.

I meant the & | ^ ~ forms would behave erratically as before, but would be numeric under the feature feature.

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @ap

Yes please.

(Can we also similarly steal xx from Perl 6? And then delete the
paragraph “There are a few exceptions” near the start of perlop?)

[p5pRT]

From @iabyn

On Sat, Dec 20, 2014 at 05​:58​:39PM -0800, Father Chrysostomos wrote​:

In order to fix the problems with & | ^ ~ having unpredictable behaviour
based on the operands’ internal flags, I propose we make them
number-specific and introduce new string-specific ops, called band, bor,
bxor and bnot. These would be enabled under a new feature.pm feature.
Outside of the feature feature, they would behave erratically as before.

+1

--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
  -- Things That Never Happen in "Star Trek" #7

[p5pRT]

From @cpansprout

On Sun Dec 21 16​:00​:46 2014, aristotle wrote​:

Yes please.

What would we call the feature feature? Just 'bitwise'?

(Can we also similarly steal xx from Perl 6? And then delete the
paragraph “There are a few exceptions” near the start of perlop?)

perlop says​:

There are a few exceptions though​: C<x> can be either string
repetition or list repetition, depending on the type of the left
operand....

I don’t think that is exactly correct. The distinction between list and string repetition is based on the syntax and the context, which is a very perl(5)ish approach. It has nothing to do with the ‘type’, whatever that might mean. @​a x 1 is a string repeat, as you know.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Sat Dec 27 10​:18​:41 2014, sprout wrote​:

On Sun Dec 21 16​:00​:46 2014, aristotle wrote​:

Yes please.

What would we call the feature feature? Just 'bitwise'?

Also, if this is required to go through the experimental cycle, then what about

use feature "bitwise";
$a = $b|$c; # guaranteed to be numeric

?

When do we emit the experimental warning? For every bitwise op (whether string or num) within the scope of that feature?

--

Father Chrysostomos

[p5pRT]

From @cpansprout

More questions​:

While x= works as an assignment operator, and looks like one, too, what about these?

$a bor= $b;
$a band= $b;
$a bxor= $b;

To me, those just look weird. Are those going to be confusing? Or will their absence be more confusing?

Should overloading have new types that fall back to qw(^ | &)?

--

Father Chrysostomos

[p5pRT]

From Eirik-Berg.Hanssen@allverden.no

On Sat, Dec 27, 2014 at 8​:03 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

While x= works as an assignment operator, and looks like one, too, what
about these?

$a bor= $b;
$a band= $b;
$a bxor= $b;

To me, those just look weird. Are those going to be confusing? Or will
their absence be more confusing?

  Their presence is going to be confusing as long as or=, and=, and xor=
remain absent.

  I don't think their absence will be confusing.

  _If_ you add them, you better add or=, and=, and xor= too. Although that
raises the spectre of not=, so ... perhaps better not. ;-)

Eirik

[p5pRT]

From @kentfredric

On 28 December 2014 at 08​:03, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

While x= works as an assignment operator, and looks like one, too, what
about these?

$a bor= $b;
$a band= $b;
$a bxor= $b;

To me, those just look weird. Are those going to be confusing? Or will
their absence be more confusing?

Should overloading have new types that fall back to qw(^ | &)?

Thinking more string-related punctuation is in order.

$x &'= $y
$x '&'=$y

Were my only two ideas. I'm not overly fond of them, but

$x band= $y

Just reads far too confusing to me.

Brain seems to be intuiting band could be an lvalue sub and trying to
assign $y to it in conjunction with some perverted indirect object
notation, and both of those are kinda "ick!".

Whereas

$x '&'= $y

Intuits I'm attempting to assign to a constant string, which I know is
impossible and will have to read documentation on wtf I'm seeing ;)

$x &'= $y

Similarly is "Huh, aint seen that before" territory, just its less
preferable to me because that notation will mess with any existing syntax
highlighters in very bad ways :)

--
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[p5pRT]

From @rcaputo

On Dec 27, 2014, at 16​:19, Kent Fredric <kentfredric@​gmail.com> wrote​:

On 28 December 2014 at 08​:03, Father Chrysostomos via RT <perlbug-followup@​perl.org <mailto​:perlbug-followup@​perl.org>> wrote​:
While x= works as an assignment operator, and looks like one, too, what about these?

$a bor= $b;
$a band= $b;
$a bxor= $b;

To me, those just look weird. Are those going to be confusing? Or will their absence be more confusing?

Should overloading have new types that fall back to qw(^ | &)?

Thinking more string-related punctuation is in order.

Or... less?

$l borwith $r;
$l bandwith $r; # not to be confused with bandwidth
$l bxorwith $r;

--
Rocco Caputo <rcaputo@​pobox.com>

[p5pRT]

From @rcaputo

On Dec 27, 2014, at 18​:07, Rocco Caputo <rcaputo@​pobox.com> wrote​:

On Dec 27, 2014, at 16​:19, Kent Fredric <kentfredric@​gmail.com <mailto​:kentfredric@​gmail.com>> wrote​:

On 28 December 2014 at 08​:03, Father Chrysostomos via RT <perlbug-followup@​perl.org <mailto​:perlbug-followup@​perl.org>> wrote​:
While x= works as an assignment operator, and looks like one, too, what about these?

$a bor= $b;
$a band= $b;
$a bxor= $b;

To me, those just look weird. Are those going to be confusing? Or will their absence be more confusing?

Should overloading have new types that fall back to qw(^ | &)?

Thinking more string-related punctuation is in order.

Or... less?

$l borwith $r;
$l bandwith $r; # not to be confused with bandwidth
$l bxorwith $r;

Or a new contextualizer?

string $l |= $r;
string $l &= $r;
string $l ^= $r;

--
Rocco Caputo <rcaputo@​pobox.com>

[p5pRT]

From @cpansprout

There is a patch on the sprout/sbit branch, for those who want to play with it. It is incomplete. Tests and documentation are absent. The single mega-patch also includes some unrelated stuff that needs to be split out. Some tests fail.

--

Father Chrysostomos

[p5pRT]

From @kentfredric

On 28 December 2014 at 12​:26, Rocco Caputo <rcaputo@​pobox.com> wrote​:

Or a new contextualizer?

I liked that idea myself initially, but the deep places of my brain had
fears about long ranging side effects from such a broad concept that would
need to be put to rest.

I mean, what will

--
sub foo {
  return $I |= $r
}

string foo;
--

do ?

I'm not saying it would be bad, but that approach feels like it needs more
thinking than I've been able to exercise so far.

--
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[p5pRT]

From @mauke

Am 21.12.2014 um 02​:58 schrieb Father Chrysostomos (via RT)​:

# New Ticket Created by Father Chrysostomos
# Please include the string​: [perl #123466]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123466 >

In order to fix the problems with & | ^ ~ having unpredictable behaviour based on the operands’ internal flags, I propose we make them number-specific and introduce new string-specific ops, called band, bor, bxor and bnot. These would be enabled under a new feature.pm feature. Outside of the feature feature, they would behave erratically as before.

I don't really like the names. There's precedent for the symbols/numeric
and words/stringy thing in ==/eq, >=/gt, etc. but those don't have
assignment variants.

. (the other major string operator) is a symbol. You could argue that x
is a word but I think it's an ASCII approximation of U+00D7
(multiplication sign) and morally punctuation.

So I think I'd prefer &. |. ^. ~. simply because &.= |.= ^.= look better
than band= bor= bxor=.

--
Lukas Mai <plokinom@​gmail.com>