search

Perl / perl5

đŸȘ The Perl programming language
https://dev.perl.org/perl5/
Other
1.92k stars 551 forks source link

Introduce string-specific bitwise ops #14348

Closed p5pRT closed 9 years ago

p5pRT commented 9 years ago

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

Searchable as RT123466$

p5pRT commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

p5pRT commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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\ 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

From @rcaputo

On Dec 27\, 2014\, at 16​:19\, Kent Fredric \kentfredric@&#8203;gmail\.com wrote​:

On 28 December 2014 at 08​:03\, Father Chrysostomos via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;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@&#8203;pobox\.com

p5pRT commented 9 years ago

From @rcaputo

On Dec 27\, 2014\, at 18​:07\, Rocco Caputo \rcaputo@&#8203;pobox\.com wrote​:

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

On 28 December 2014 at 08​:03\, Father Chrysostomos via RT \<perlbug-followup@​perl.org \mailto&#8203;:perlbug\-followup@&#8203;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@&#8203;pobox\.com

p5pRT commented 9 years ago

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 commented 9 years ago

From @kentfredric

On 28 December 2014 at 12​:26\, Rocco Caputo \rcaputo@&#8203;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 commented 9 years ago

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@&#8203;gmail\.com

p5pRT commented 9 years ago

From @cpansprout

On Sun Dec 28 00​:59​:52 2014\, plokinom@​gmail.com wrote​:

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=.

I think I prefer those\, too. But I really hope the pumpking will speak up\, because any more work I do on this will just have to be redone if the spelling changes.

If we do use the alphabetic names\, omitting the assignment ops might be the best thing\, but we could still optimise ‘$a = $a bxor $b’ to bxor= internally even if we have no bxor=.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @arc

Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

On Sun Dec 28 00​:59​:52 2014\, plokinom@​gmail.com wrote​:

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

I think I prefer those\, too. But I really hope the pumpking will speak up\, because any more work I do on this will just have to be redone if the spelling changes.

As it happens\, those were the spellings I'd independently come up with\, too. Their obvious flaw is that the dot might tend to get lost visually\, but they're internally consistent\, and do have some mnemonic value.

If we do use the alphabetic names\, omitting the assignment ops might be the best thing\, but we could still optimise ‘$a = $a bxor $b’ to bxor= internally even if we have no bxor=.

There are situations in which it would be awkward to spell the long-hand version\, optimisation notwithstanding. This is fine​:

$h{ has_side_effects() } += $x;

This would be vexatious​:

my $key = has_side_effects(); $h{$key} = $h{$key} bxor $x;

Not to mention that\, as the lvalue gets more complex\, there's a corresponding increase in value to the programmer of not having to repeat it\, in that repeating a long expression is error-prone.

Put simply​: I'd find it annoying for there to be no augmented-assignment version of new string-specific bitwise ops.

-- Aaron Crane ** http​://aaroncrane.co.uk/

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2014-12-28T16​:18​:31]

On Sun Dec 28 00​:59​:52 2014\, plokinom@​gmail.com wrote​:

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

I think I prefer those\, too. But I really hope the pumpking will speak up\, because any more work I do on this will just have to be redone if the spelling changes.

I've been following along and brooding silently\, as is my wont. I'd like to claim that I did it at midnight perched on a gargoyle\, but Bethlehem isn't a very vertical city. Mostly\, I've been on my sofa.

I am generally in favor of this feature.

I actually think that "band" looks better than "&."\, and by a significant amount. &. looks to me like all the tired complaints about Perl syntax.

Too bad for me\, though\, that I don't think it's just down to aesthetics.

I think that the parallel between "or" and "||" will be brought more readily to mind than that between "eq" and "==". Also\, while I want to put on a brave face about "band="\, I don't think it will "look right."

So\, tentatively\, &. |. and ^. look saner. Ah well.

That said​: Do we expect difficulties from &. which is already syntactic\, meaning the subroutine in the *. glob?

-- rjbs

p5pRT commented 9 years ago

From @bulk88

Lukas Mai wrote​:

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

"band" is a word\, not a combination of 2 words. band() might as well be equivalent to [] or {} operator or bless() in an alternative universe. Punctuation is better than more words. Perl shouldn't look like Python or VB.

p5pRT commented 9 years ago

From @cpansprout

On Mon Dec 29 18​:46​:23 2014\, perl.p5p@​rjbs.manxome.org wrote​:

That said​: Do we expect difficulties from &. which is already syntactic\, meaning the subroutine in the *. glob?

Currently &. cannot mean &{.} where an operator is expected. Instead\, it is only valid when followed by a number\, as in ‘1 &.2’. The same difficulty with .2 applies to all the ops. I would suggest we only allow &. ^. ~. |. to be interpreted as operators when not followed immediately by a digit\, sidestepping the whole back-compat issue. (Pusillanimity is an amazing time saver.)

--

Father Chrysostomos

p5pRT commented 9 years ago

From @leonerd

I like the idea of using words for stringy operators here.

There's a certain symmetry with​:

\< \<= \<=> => > for integers lt le cmp ge gt for strings

Then we'd have​:

& | ^ for integers band bor bxor for strings

-- Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk http​://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2014-12-30T00​:40​:01]

On Mon Dec 29 18​:46​:23 2014\, perl.p5p@​rjbs.manxome.org wrote​:

That said​: Do we expect difficulties from &. which is already syntactic\, meaning the subroutine in the *. glob?

Currently &. cannot mean &{.} where an operator is expected.

  use 5.12.0;   *. = sub { say "dot​: @​_" };   sub foo { say "foo​: @​_" }   sub bar { "bar" }

  foo &. (bar());

  __END__   dot​: bar   foo​: 1

-- rjbs

p5pRT commented 9 years ago

From @cpansprout

On Tue Dec 30 06​:50​:54 2014\, perl.p5p@​rjbs.manxome.org wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2014-12- 30T00​:40​:01]

On Mon Dec 29 18​:46​:23 2014\, perl.p5p@​rjbs.manxome.org wrote​:

That said​: Do we expect difficulties from &. which is already syntactic\, meaning the subroutine in the *. glob?

Currently &. cannot mean &{.} where an operator is expected.

use 5.12.0; *. = sub { say "dot​: @​_" }; sub foo { say "foo​: @​_" } sub bar { "bar" }

foo &. (bar());

__END__ dot​: bar foo​: 1

That does not disagree with what I said. By operator I meant specifically an infix operator. foo * 3 in that context would be foo(*{3})\, not foo() * 3. So * and & would behave similarly.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2014-12-30T15​:48​:40]

That does not disagree with what I said. By operator I meant specifically an infix operator. foo * 3 in that context would be foo(*{3})\, not foo() * 3. So * and & would behave similarly.

I must admit to being surprised! I didn't add a demonstration of (foo x bar) or (foo * bar) because I thought their behavior was self-evident. Ho ho ho.

I will reread and rereply next year.

-- rjbs

p5pRT commented 9 years ago

From @kentfredric

On 28 December 2014 at 12​:26\, Rocco Caputo \rcaputo@&#8203;pobox\.com wrote​:

Or a new contextualizer?

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

Actually\, on second thoughts\, that could kinda work without long ranging side effects as long as you made it

a) strictly lexical b) strictly compile time

So that the "contextualiser" was simply the inverse behaviour of "use feature \<no_bitwise_strings>" or whatever.

thus my worries about how it would propagate to subs would be negligible.

And there are two ways one could implement such a feature​:

- lexical use flags​:

{   use bitops 'string';   $x |= $r ; # always stringwise in this context   use bitops 'number';   $x |= $r ; # numeric bitwise }

or a lexical structure​:

  $foo = string { $x |= $r }; # stringwise   $foo = $x |= $r # non stringwise

  $foo = string $x |= $r # could be made work with an implicit scope to the end of the statement\, but seems dangerous.

-- Kent

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

p5pRT commented 9 years ago

From @cpansprout

On Wed Dec 31 16​:02​:50 2014\, kentfredric@​gmail.com wrote​:

- lexical use flags​:

{ use bitops 'string'; $x |= $r ; # always stringwise in this context use bitops 'number'; $x |= $r ; # numeric bitwise }

I hadn’t thought of bitops pragma. We could do it that way. I think I prefer separate operators. In any case\, I don’t think it matters so much\, as long as ‘use v5.xx’ eventually disables the bipolar behaviour. But it seems the pumpking has settled on &. etc.\, and shedding bikes may be less than profitable at this stage.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2014-12-31T19​:55​:18]

I hadn’t thought of bitops pragma. We could do it that way. I think I prefer separate operators.

Me\, too. Although both involve a pragma changing the behavior of existing operators\, your preexisting proposal is one setting that can apply everywhere. Kent's proposal would have to be turned off and on here and there\, making the code harder to skim.

In any case\, I don’t think it matters so much\, as long as ‘use v5.xx’ eventually disables the bipolar behaviour. But it seems the pumpking has settled on &. etc.\, and shedding bikes may be less than profitable at this stage.

Nihil obstat.

-- rjbs

p5pRT commented 9 years ago

From @cpansprout

I have pushed a new version of the sprout/sbit branch\, which implements &.\, &.=\, etc. It has yet to emit an experimental warning.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @cpansprout

How should ‘&’ overloading work in the presence of the ‘bitwise’ feature?

Up till now it has been up to the overload implementation to decide whether & and | should have stringy or numeric behaviour. But under the ‘bitwise’ feature it is the caller that decides.

So\, under that feature\, should we use the existing overload types (& | ^ ~) for the numeric ops? Or should we introduce a new set of number-specific overload types that those ops trigger under the feature? (I plan to introduce new overload types for the string-specific ops either way\, since they are brand new operators [&. |. ^. ~.].)

In the first case\, object implementations that want to know whether the caller specifically requested numeric behaviour will have to look at feature hints. For warnings\, we provide warnings​::enabled\, but feature.pm provides no such interface. Should it? (I don’t like the idea of adding it\, because I prefer to think of feature.pm as a back-end for ‘use v5.xx’ and experimental.pm. And whether a particular language feature has anything to do with feature.pm may be subject to change.)

In the second case\, it might be confusing to have a separate num& overload type; even if it is not confusing\, it is a bit clunky.

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

What I would like to do is just use & for &\, leave feature.pm alone\, and recommend that & overloads be number-specific regardless of perl version. That seems the simplest and most straightforward approach overall.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-04T17​:40​:13]

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

Yes\, although most often I've seen it used for logical purposes\, like​:

  $newset = $set1 ^ $set2;

What I would like to do is just use & for &\, leave feature.pm alone\, and recommend that & overloads be number-specific regardless of perl version. That seems the simplest and most straightforward approach overall.

I think this is probably correct\, but I want to think about it a lot more than the 45s I just did. Hopefully other people will have interesting things to say before I do that. ;)

-- rjbs

p5pRT commented 9 years ago

From @cpansprout

On Sun Jan 04 16​:45​:52 2015\, perl.p5p@​rjbs.manxome.org wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01- 04T17​:40​:13]

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

Yes\, although most often I've seen it used for logical purposes\, like​:

$newset = $set1 ^ $set2;

What I would like to do is just use & for &\, leave feature.pm alone\, and recommend that & overloads be number-specific regardless of perl version. That seems the simplest and most straightforward approach overall.

I think this is probably correct\, but I want to think about it a lot more than the 45s I just did. Hopefully other people will have interesting things to say before I do that. ;)

I have just pushed a new sprout/sbit branch that implements the entire feature\, including documentation and tests. It just lacks a note in overload.pm explaining the dual nature of qw(& | ^ ~).

--

Father Chrysostomos

p5pRT commented 9 years ago

From @ap

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-04 23​:45]​:

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

I’ve seen | overloaded to mean a shell pipe between process objects.

I’ve seen & overloaded for something that likewise had nothing to do with bitwise logic\, though what it was escapes me.

You cannot avoid calling these overloads.

Maybe overloads of the numeric bitwise ops would receive a new fourth argument which is true for a purely-numeric bitwise op and false for a mixed-mode op? Instead of sending the caller out to fuss about with hints in order to find that information\, you just give it to them. No?

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

p5pRT commented 9 years ago

From @cpansprout

On Mon Jan 05 22​:02​:36 2015\, aristotle wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-04 23​:45]​:

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

I’ve seen | overloaded to mean a shell pipe between process objects.

I’ve seen & overloaded for something that likewise had nothing to do with bitwise logic\, though what it was escapes me.

VB-style concatenation? :-)

You cannot avoid calling these overloads.

Maybe overloads of the numeric bitwise ops would receive a new fourth argument which is true for a purely-numeric bitwise op and false for a mixed-mode op? Instead of sending the caller out to fuss about with hints in order to find that information\, you just give it to them. No?

Of course! Aristotle’s brain to the rescue! :-) That fits in perfectly with the existing behaviour\, yet it completely escaped me.

--

Father Chrysostomos

p5pRT commented 9 years ago

From @cpansprout

On Mon Jan 05 22​:02​:36 2015\, aristotle wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-04 23​:45]​:

Does anybody currently overload & | ^ ~ for non-numeric uses? The only use of these I am aware of is by modules like Math​::BigInt\, etc.

I’ve seen | overloaded to mean a shell pipe between process objects.

I’ve seen & overloaded for something that likewise had nothing to do with bitwise logic\, though what it was escapes me.

You cannot avoid calling these overloads.

Maybe overloads of the numeric bitwise ops would receive a new fourth argument which is true for a purely-numeric bitwise op and false for a mixed-mode op? Instead of sending the caller out to fuss about with hints in order to find that information\, you just give it to them. No?

Most overload handlers get passed 3 arguments. nomethod handlers are passed four\, the fourth being the operator in question.

For & do we pass a boolean as a 4th or 5th argument indicating numericalness depending on whether it is a nomethod handler? Or do we make it always the 5th argument?

--

Father Chrysostomos

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-09T01​:24​:57]

For & do we pass a boolean as a 4th or 5th argument indicating numericalness depending on whether it is a nomethod handler? Or do we make it always the 5th argument?

Always 5th.

-- rjbs

p5pRT commented 9 years ago

From @ap

* Ricardo Signes \perl\.p5p@&#8203;rjbs\.manxome\.org [2015-01-09 23​:30]​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-09T01​:24​:57]

For & do we pass a boolean as a 4th or 5th argument indicating numericalness depending on whether it is a nomethod handler? Or do we make it always the 5th argument?

Always 5th.

Concur.

p5pRT commented 9 years ago

From @rjbs

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2015-01-04T20​:55​:59]

I have just pushed a new sprout/sbit branch that implements the entire feature\, including documentation and tests. It just lacks a note in overload.pm explaining the dual nature of qw(& | ^ ~).

It so happens that I'm taking an online course this winter on cryptography. It's fun! It also means that I have some code sitting around with some stringly bitwise ops. I switched some of it to use this and found it unobjectionable.

I hope to try doing some more substantial work with it...

-- rjbs

p5pRT commented 9 years ago

From @cpansprout

It’s in​: df442ae4

--

Father Chrysostomos

p5pRT commented 9 years ago

@cpansprout - Status changed from 'open' to 'resolved'