Introduce string-specific bitwise ops #14348
Comments
From @cpansproutIn 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 |
From @cpansproutOn Sat Dec 20 17:58:39 2014, sprout wrote:
I meant the & | ^ ~ forms would behave erratically as before, but would be numeric under the feature feature. -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @apYes please. (Can we also similarly steal xx from Perl 6? And then delete the |
From @iabynOn Sat, Dec 20, 2014 at 05:58:39PM -0800, Father Chrysostomos wrote:
+1 -- |
From @cpansproutOn Sun Dec 21 16:00:46 2014, aristotle wrote:
What would we call the feature feature? Just 'bitwise'?
perlop says: There are a few exceptions though: C<x> can be either string 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 |
From @cpansproutOn Sat Dec 27 10:18:41 2014, sprout wrote:
Also, if this is required to go through the experimental cycle, then what about use feature "bitwise"; ? When do we emit the experimental warning? For every bitwise op (whether string or num) within the scope of that feature? -- Father Chrysostomos |
From @cpansproutMore questions: While x= works as an assignment operator, and looks like one, too, what about these? $a bor= $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 |
From Eirik-Berg.Hanssen@allverden.noOn Sat, Dec 27, 2014 at 8:03 PM, Father Chrysostomos via RT <
Their presence is going to be confusing as long as or=, and=, and xor= I don't think their absence will be confusing. _If_ you add them, you better add or=, and=, and xor= too. Although that Eirik |
From @kentfredricOn 28 December 2014 at 08:03, Father Chrysostomos via RT <
Thinking more string-related punctuation is in order. $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 Whereas $x '&'= $y Intuits I'm attempting to assign to a constant string, which I know is $x &'= $y Similarly is "Huh, aint seen that before" territory, just its less -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @rcaputo
Or... less? $l borwith $r; -- |
From @rcaputo
Or a new contextualizer? string $l |= $r; -- |
From @cpansproutThere 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 |
From @kentfredricOn 28 December 2014 at 12:26, Rocco Caputo <rcaputo@pobox.com> wrote:
I liked that idea myself initially, but the deep places of my brain had I mean, what will -- string foo; do ? I'm not saying it would be bad, but that approach feels like it needs more -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @maukeAm 21.12.2014 um 02:58 schrieb Father Chrysostomos (via RT):
I don't really like the names. There's precedent for the symbols/numeric . (the other major string operator) is a symbol. You could argue that x So I think I'd prefer &. |. ^. ~. simply because &.= |.= ^.= look better -- |
From @cpansproutOn Sun Dec 28 00:59:52 2014, plokinom@gmail.com wrote:
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 @arcFather Chrysostomos via RT <perlbug-followup@perl.org> wrote:
As it happens, those were the spellings I'd independently come up
There are situations in which it would be awkward to spell the $h{ has_side_effects() } += $x; This would be vexatious: my $key = has_side_effects(); Not to mention that, as the lvalue gets more complex, there's a Put simply: I'd find it annoying for there to be no -- |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-28T16:18:31]
I've been following along and brooding silently, as is my wont. I'd like to I am generally in favor of this feature. I actually think that "band" looks better than "&.", and by a significant 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 So, tentatively, &. |. and ^. look saner. Ah well. That said: Do we expect difficulties from &. which is already syntactic, -- |
From @bulk88Lukas Mai wrote:
"band" is a word, not a combination of 2 words. band() might as well be |
From @cpansproutOn Mon Dec 29 18:46:23 2014, perl.p5p@rjbs.manxome.org wrote:
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 |
From @leonerdI like the idea of using words for stringy operators here. There's a certain symmetry with: < <= <=> => > for integers Then we'd have: & | ^ for integers -- leonerd@leonerd.org.uk |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-30T00:40:01]
use 5.12.0; foo &. (bar()); __END__ -- |
From @cpansproutOn Tue Dec 30 06:50:54 2014, perl.p5p@rjbs.manxome.org wrote:
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 |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-30T15:48:40]
I must admit to being surprised! I didn't add a demonstration of (foo x bar) I will reread and rereply next year. -- |
From @kentfredricOn 28 December 2014 at 12:26, Rocco Caputo <rcaputo@pobox.com> wrote:
Actually, on second thoughts, that could kinda work without long ranging a) strictly lexical So that the "contextualiser" was simply the inverse behaviour of "use 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: { or a lexical structure: $foo = string { $x |= $r }; # stringwise $foo = string $x |= $r # could be made work with an implicit scope -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @cpansproutOn Wed Dec 31 16:02:50 2014, kentfredric@gmail.com wrote:
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 |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-12-31T19:55:18]
Me, too. Although both involve a pragma changing the behavior of existing
Nihil obstat. -- |
From @cpansproutI have pushed a new version of the sprout/sbit branch, which implements &., &.=, etc. It has yet to emit an experimental warning. -- Father Chrysostomos |
From @cpansproutHow 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 @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04T17:40:13]
Yes, although most often I've seen it used for logical purposes, like: $newset = $set1 ^ $set2;
I think this is probably correct, but I want to think about it a lot more than -- |
From @cpansproutOn Sun Jan 04 16:45:52 2015, perl.p5p@rjbs.manxome.org wrote:
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 |
From @ap* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04 23:45]:
I’ve seen | overloaded to mean a shell pipe between process objects. I’ve seen & overloaded for something that likewise had nothing to do You cannot avoid calling these overloads. Maybe overloads of the numeric bitwise ops would receive a new fourth Regards, |
From @cpansproutOn Mon Jan 05 22:02:36 2015, aristotle wrote:
VB-style concatenation? :-)
Of course! Aristotle’s brain to the rescue! :-) That fits in perfectly with the existing behaviour, yet it completely escaped me. -- Father Chrysostomos |
From @cpansproutOn Mon Jan 05 22:02:36 2015, aristotle wrote:
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 |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-09T01:24:57]
Always 5th. -- |
From @ap* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-01-09 23:30]:
Concur. |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2015-01-04T20:55:59]
It so happens that I'm taking an online course this winter on cryptography. I hope to try doing some more substantial work with it... -- |
From @cpansproutIt’s in: df442ae -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#123466 (status was 'resolved')
Searchable as RT123466$
The text was updated successfully, but these errors were encountered: