Skip Menu |

Subject: Introduce string-specific bitwise ops
Download (untitled) / with headers
text/plain 381b
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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 547b
On Sat Dec 20 17:58:39 2014, sprout wrote: Show quoted text
> 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
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Date: Mon, 22 Dec 2014 01:00:18 +0100
Download (untitled) / with headers
text/plain 150b
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?)
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Date: Thu, 25 Dec 2014 10:48:27 +0000
From: Dave Mitchell <davem [...] iabyn.com>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 594b
On Sat, Dec 20, 2014 at 05:58:39PM -0800, Father Chrysostomos wrote: Show quoted text
> 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 719b
On Sun Dec 21 16:00:46 2014, aristotle wrote: Show quoted text
> Yes please.
What would we call the feature feature? Just 'bitwise'? Show quoted text
> (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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 465b
On Sat Dec 27 10:18:41 2014, sprout wrote: Show quoted text
> 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 338b
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
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: Eirik Berg Hanssen <Eirik-Berg.Hanssen [...] allverden.no>
Date: Sat, 27 Dec 2014 21:32:25 +0100
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 629b

On Sat, Dec 27, 2014 at 8:03 PM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
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
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
From: Kent Fredric <kentfredric [...] gmail.com>
To: Lukas Mai via RT <perlbug-followup [...] perl.org>
Date: Sun, 28 Dec 2014 10:19:20 +1300
CC: pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.1k

On 28 December 2014 at 08:03, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
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 :)
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
To: Kent Fredric <kentfredric [...] gmail.com>
From: Rocco Caputo <rcaputo [...] pobox.com>
Date: Sat, 27 Dec 2014 18:07:59 -0500
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 711b
Show quoted text
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> 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>
From: Rocco Caputo <rcaputo [...] pobox.com>
To: Kent Fredric <kentfredric [...] gmail.com>
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Date: Sat, 27 Dec 2014 18:26:40 -0500
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 919b
Show quoted text
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> wrote:

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.

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>
Show quoted text
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 266b
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
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
From: Kent Fredric <kentfredric [...] gmail.com>
To: Rocco Caputo <rcaputo [...] pobox.com>
Date: Sun, 28 Dec 2014 15:24:29 +1300
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 533b

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

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.
Date: Sun, 28 Dec 2014 09:59:22 +0100
To: perl5-porters [...] perl.org
From: Lukas Mai <plokinom [...] gmail.com>
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Download (untitled) / with headers
text/plain 1.1k
Am 21.12.2014 um 02:58 schrieb Father Chrysostomos (via RT): Show quoted text
> # 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.perl.org/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>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Sun Dec 28 00:59:52 2014, plokinom@gmail.com wrote: Show quoted text
> 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.perl.org/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
From: Aaron Crane <arc [...] cpan.org>
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Sun, 28 Dec 2014 22:54:35 +0000
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: Show quoted text
> 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. Show quoted text
> 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/
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
CC: ;, perl5-porters [...] perl.org
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Mon, 29 Dec 2014 21:45:58 -0500
Download (untitled) / with headers
text/plain 1.2k
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-28T16:18:31] Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #123466] Introduce string-specific bitwise ops
CC: perl5-porters [...] perl.org
From: bulk88 <bulk88 [...] hotmail.com>
To: Lukas Mai <plokinom [...] gmail.com>
Date: Mon, 29 Dec 2014 23:08:55 -0500
Download (untitled) / with headers
text/plain 344b
Lukas Mai wrote: Show quoted text
> 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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 596b
On Mon Dec 29 18:46:23 2014, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> 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
CC: perlbug-followup [...] perl.org
Date: Tue, 30 Dec 2014 12:13:26 +0000
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
From: "Paul \"LeoNerd\" Evans" <leonerd [...] leonerd.org.uk>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 350b
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
Download signature.asc
application/pgp-signature 213b

Message body not shown because it is not plain text.

Date: Tue, 30 Dec 2014 09:50:27 -0500
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
CC: ;, perl5-porters [...] perl.org
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Download (untitled) / with headers
text/plain 487b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-30T00:40:01] Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 778b
On Tue Dec 30 06:50:54 2014, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@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
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 31 Dec 2014 17:57:55 -0500
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
CC: ;, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 478b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-30T15:48:40] Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: Kent Fredric <kentfredric [...] gmail.com>
To: Rocco Caputo <rcaputo [...] pobox.com>
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
CC: Lukas Mai via RT <perlbug-followup [...] perl.org>, pp Porters <perl5-porters [...] perl.org>
Date: Thu, 1 Jan 2015 13:02:26 +1300

On 28 December 2014 at 12:26, Rocco Caputo <rcaputo@pobox.com> wrote:
Show quoted text
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.


   
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 594b
On Wed Dec 31 16:02:50 2014, kentfredric@gmail.com wrote: Show quoted text
> - 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
CC: ;, perl5-porters [...] perl.org
Subject: Re: [perl #123466] Introduce string-specific bitwise ops
Date: Fri, 2 Jan 2015 08:03:40 -0500
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 704b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-31T19:55:18] Show quoted text
> 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. Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 157b
I have pushed a new version of the sprout/sbit branch, which implements &., &.=, etc. It has yet to emit an experimental warning. -- Father Chrysostomos
Subject: Overloading for number-specific bitwise ops
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
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
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
Date: Sun, 4 Jan 2015 19:44:36 -0500
Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
CC: ;, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 732b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04T17:40:13] Show quoted text
> 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; Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
RT-Send-CC: perl5-porters [...] perl.org
On Sun Jan 04 16:45:52 2015, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@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
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
Date: Tue, 6 Jan 2015 07:02:13 +0100
Download (untitled) / with headers
text/plain 801b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04 23:45]: Show quoted text
> 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/>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1001b
On Mon Jan 05 22:02:36 2015, aristotle wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@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? :-) Show quoted text
> 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
Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
On Mon Jan 05 22:02:36 2015, aristotle wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@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
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Fri, 9 Jan 2015 17:27:15 -0500
Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
CC: ;, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 275b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-09T01:24:57] Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: perl5-porters [...] perl.org
Date: Sat, 10 Jan 2015 05:50:03 +0100
Download (untitled) / with headers
text/plain 350b
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-01-09 23:30]: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@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.
Subject: Re: [perl #123466] Overloading for number-specific bitwise ops
CC: ;, perl5-porters [...] perl.org
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Thu, 15 Jan 2015 22:16:28 -0500
Download (untitled) / with headers
text/plain 584b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04T20:55:59] Show quoted text
> 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
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
It’s in: df442ae4 -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org