Skip Menu |
Report information
Id: 130540
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: fernandocorrea [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
Date: Tue, 10 Jan 2017 22:22:39 -0200
From: Fernando Oliveira <fernandocorrea [...] gmail.com>
Subject: [BUG] || && and or cannot be "overloaded"
Download (untitled) / with headers
text/plain 189b
If I write another || operator it will continue to use the original version.

https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 542b
On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote: Show quoted text
> If I write another || operator it will continue to use the original > version. > > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 > <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823>
To save other readers sifting through the chan log... Even an only sub doesn't take root: <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55 <camelia> rakudo-moar 9a11ea: OUTPUT«42␤» This applies to &&, and, or, and I'd guess any shortcurcuiting operator.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 793b
On Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote: Show quoted text
> On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote:
> > If I write another || operator it will continue to use the original > > version. > > > > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 > > <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823>
> > To save other readers sifting through the chan log... Even an only sub > doesn't take root: > > <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55 > <camelia> rakudo-moar 9a11ea: OUTPUT«42␤» > > This applies to &&, and, or, and I'd guess any shortcurcuiting > operator.
These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override.
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
To: perl6-bugs-followup [...] perl.org
Date: Thu, 12 Jan 2017 05:28:29 +0000
Subject: Re: [perl #130540] [BUG] || && and or cannot be "overloaded"
CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
There is a &infix:<&&> which might be where some confusion comes from. I guess that's there for meta operators. For example:

multi sub infix:<&&>("foo","bar") { "win" };
say "foo" && "bar" # bar
say <foo> Z&& <bar> # win

so it does kinda work actually just not as you might expect.

LL


On Thu, Jan 12, 2017 at 9:21 AM jnthn@jnthn.net via RT <perl6-bugs-followup@perl.org> wrote:
Show quoted text
On Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote:
> On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote:
> > If I write another || operator it will continue to use the original
> > version.
> >
> > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823
> > <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823>
>
> To save other readers sifting through the chan log... Even an only sub
> doesn't take root:
>
> <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55
> <camelia> rakudo-moar 9a11ea: OUTPUT«42␤»
>
> This applies to &&, and, or, and I'd guess any shortcurcuiting
> operator.

These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override.
Subject: Re: [perl #130540] [BUG] || && and or cannot be "overloaded"
To: "Christian Bartolomaeus (via RT)" <perl6-bugs-followup [...] perl.org>
Date: Thu, 12 Jan 2017 10:24:08 +0100
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Download (untitled) / with headers
text/plain 1.9k
[10:04:44] <lizmat> re the shortcircuiting behaviour of && || and friends, and the fact you cannot override them (RT #130540) [10:05:09] <lizmat> I wonder whether we perhaps need a new kind of signature that would make this work: [10:05:20] <lizmat> sub a(*@a) { dd @a.shift }; my $a = 0; a $a++,$a++; dd $a # sorta expected to see $a = 1 here [10:05:27] <lizmat> m: sub a(*@a) { dd @a.shift }; my $a = 0; a $a++,$a++; dd $a [10:05:27] <camelia> rakudo-moar 8f3476: OUTPUT«0␤Int $a = 2␤» [10:05:52] <lizmat> aka, a lazy slurpy signature [10:06:41] <lizmat> which would allow && || and friends to become full HLL citizens, rather then needing to be handled at codegen level and thus make them unoverridable Show quoted text
> On 12 Jan 2017, at 06:28, Lloyd Fournier <lloyd.fourn@gmail.com> wrote: > > There is a &infix:<&&> which might be where some confusion comes from. I guess that's there for meta operators. For example: > multi sub infix:<&&>("foo","bar") { "win" }; > say "foo" && "bar" # bar > say <foo> Z&& <bar> # win > > so it does kinda work actually just not as you might expect. > > LL > > > On Thu, Jan 12, 2017 at 9:21 AM jnthn@jnthn.net via RT <perl6-bugs-followup@perl.org> wrote: > On Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote:
> > On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote:
> > > If I write another || operator it will continue to use the original > > > version. > > > > > > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 > > > <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823>
> > > > To save other readers sifting through the chan log... Even an only sub > > doesn't take root: > > > > <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55 > > <camelia> rakudo-moar 9a11ea: OUTPUT«42␤» > > > > This applies to &&, and, or, and I'd guess any shortcurcuiting > > operator.
> > These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override.
Download (untitled) / with headers
text/plain 1.1k
@lizmat: Aren't signatures that affect how a function call is parsed/compiled (a la Perl 5 "prototypes"), something that Perl 6 intentionally moved away from? Regarding the "thunky" operators like ||, &&, xx: My conceptual view of them, is that each of them exists simultaneously as a macro (that offers the short-circuiting/lazy-evaluation behavior) and as function (which accepts Perl 6 objects rather than thunks). The macro clobbers the function, so when the operator is encountered normally in the source code, the compiler (conceptually) invokes the macro, thus generating code for the lazy evaluation behavior. But you actually *can* get at the function version as well, which obviously can't be short-circuiting/lazy: ➜ say &[||] sub infix:<||> (| is raw) { #`(Sub+{Precedence}|64299168) ... } ➜ say &[||](0, 5) 5 ➜ say &[||]( 1, say("Hi") ) Hi 1 In this view, adding a multi candidate to the function does nothing to override the macro, so this wouldn't be considered a bug. Rather, the solution would be to provide sufficiently flexible macro functionality to allow users to override or extend these built-in macros.
Subject: Re: [perl #130540] [BUG] || && and or cannot be "overloaded"
Date: Wed, 11 Jan 2017 20:42:05 -0200
To: perl6-bugs-followup [...] perl.org
From: Fernando Oliveira <fernandocorrea [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
But should those 2 forms behave differently? 20:40 <SmokeMachine> m: multi infix:<||>(42, 42) {"OK"}; say infix:<||>(42, 42); say 42 || 42 20:40 <camelia> rakudo-moar 8f3476: OUTPUT«OK␤42␤» Enviado do meu iPhone Show quoted text
> Em 11 de jan de 2017, às 20:20, jnthn@jnthn.net via RT <perl6-bugs-followup@perl.org> escreveu: >
>> On Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote:
>>> On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote: >>> If I write another || operator it will continue to use the original >>> version. >>> >>> https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 >>> <https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823>
>> >> To save other readers sifting through the chan log... Even an only sub >> doesn't take root: >> >> <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55 >> <camelia> rakudo-moar 9a11ea: OUTPUT«42␤» >> >> This applies to &&, and, or, and I'd guess any shortcurcuiting >> operator.
> > These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override. >
Subject: Re: [perl #130540] [BUG] || && and or cannot be "overloaded"
To: "(via RT)" <perl6-bugs-followup [...] perl.org>
Date: Thu, 12 Jan 2017 21:09:59 +0100
From: Bart Wiegmans <bartwiegmans [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
I'm not sure if this adds anything, but:
The reason why infix<||> doesn't work as you'd expect, is that operators like '||' and '&&' operate on expressions, that is to say code, rather than on values.
The only valid way to extend such operators is to either use macros (which would receive both sides as arguments) or to create 'thunks' out of both sides. 
Either way, a sub that takes value arguments is incompatible with the short-circuiting semantics, and I think it should fail at compile time.

Regards,
Bart

2017-01-11 23:42 GMT+01:00 Fernando Oliveira <fernandocorrea@gmail.com>:
Show quoted text
But should those 2 forms behave differently?

20:40 <SmokeMachine> m: multi infix:<||>(42, 42) {"OK"}; say infix:<||>(42, 42); say 42 || 42
20:40 <camelia> rakudo-moar 8f3476: OUTPUT«OK␤42␤»

Enviado do meu iPhone

> Em 11 de jan de 2017, às 20:20, jnthn@jnthn.net via RT <perl6-bugs-followup@perl.org> escreveu:
>
>> On Tue, 10 Jan 2017 17:59:05 -0800, cpan@zoffix.com wrote:
>>> On Tue, 10 Jan 2017 16:23:18 -0800, fernandocorrea@gmail.com wrote:
>>> If I write another || operator it will continue to use the original
>> To save other readers sifting through the chan log... Even an only sub
>> doesn't take root:
>>
>> <Zoffix> m: sub infix:<||> ($, $) {"hi"}; say 42 || 55
>> <camelia> rakudo-moar 9a11ea: OUTPUT«42␤»
>>
>> This applies to &&, and, or, and I'd guess any shortcurcuiting
>> operator.
>
> These are special compiler forms that receive special code-gen, due to their shortcircuiting nature, and so do not result in sub calls. Thus there's no sub to override.
>



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