Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce string-specific bitwise ops #14348

Closed
p5pRT opened this issue Dec 21, 2014 · 39 comments
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Dec 21, 2014

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

Searchable as RT123466$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2014

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 22, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 25, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2014

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>

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2014

From @arc

Father Chrysostomos via RT <perlbug-followup@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

From @rjbs

* 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

--
rjbs

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 30, 2014

From @cpansprout

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

* 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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 31, 2014

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 1, 2015

From @kentfredric

On 28 December 2014 at 12​:26, Rocco Caputo <rcaputo@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 1, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 2, 2015

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 4, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 4, 2015

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 5, 2015

From @rjbs

* 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. ;)

--
rjbs

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 5, 2015

From @cpansprout

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

* 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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 6, 2015

From @ap

* 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?

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 6, 2015

From @cpansprout

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

* 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? :-)

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 9, 2015

From @cpansprout

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

* 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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 9, 2015

From @rjbs

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

--
rjbs

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 10, 2015

From @ap

* Ricardo Signes <perl.p5p@​rjbs.manxome.org> [2015-01-09 23​:30]​:

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 16, 2015

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 1, 2015

From @cpansprout

It’s in​: df442ae

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 1, 2015

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

@p5pRT p5pRT closed this Feb 1, 2015
@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.