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

Owner: Nobody
Requestors: j.david.lowe [at] apple.com
smls75 [at] gmail.com
Cc:
AdminCc:

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



To: rakudobug [...] perl.org
Subject: [LTA] `but role { ... }` interacts strangely with outer lexicals, and doesn't warn about it
From: "Sam S." <smls75 [...] gmail.com>
Date: Thu, 9 Mar 2017 16:35:23 +0100
Download (untitled) / with headers
text/plain 449b
sub a ($a) { return True but role { method foo { $a } } } my $x = a 42; say $x.foo; # 42 my $y = a "Hello"; say $y.foo; # Hello say $x.foo; # Hello I have a suspicion that this is not a bug but rather a consequence of classes/roles not being proper closures. But the current behavior is rather LTA in cases like this. Could this possibly be made to emit a warning?
Date: Thu, 9 Mar 2017 16:39:17 +0100
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #130965] [LTA] `but role { ... }` interacts strangely with outer lexicals, and doesn't warn about it
To: "Sam S. (via RT)" <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1017b
Yes, this is because classes / roles are not proper closures. And yes, I’ve been bitten by this as well. To me, making them proper closures, feels like the correct solution to me. But I’ll settle for a warning / exceptione :-) Show quoted text
> On 9 Mar 2017, at 16:35, Sam S. (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by Sam S. > # Please include the string: [perl #130965] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=130965 > > > > sub a ($a) { > return True but role { > method foo { $a } > } > } > > my $x = a 42; > say $x.foo; # 42 > > my $y = a "Hello"; > say $y.foo; # Hello > say $x.foo; # Hello > > I have a suspicion that this is not a bug but rather a consequence of > classes/roles not being proper closures. > > But the current behavior is rather LTA in cases like this. > Could this possibly be made to emit a warning?
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote: Show quoted text
> Yes, this is because classes / roles are not proper closures. And > yes, I’ve been bitten by this as well. >
It boils down to roles and classes being compile-time constructs, while closures are decidedly runtime ones. You can force a role to be re-evaluated each time by making it parametric, and passing the state as a role parameter. Note, however, that roles are interned based on the object identity of their positional parameters. This means the pattern, used on values, has a high chance of causing a memory "leak". Note that the `but RoleName($value)` syntax that mixes in the role and, if it has a single attribute, assigns $value to it, is there to make cases like this a bit more convenient. Show quoted text
> To me, making them proper closures, feels like the correct solution to > me.
For this to happen we'd need: * To clone the methods, attribute initialization closures, etc. * To therefore have a cloned method table, Attribute objects, etc. to point to these clones * Which implies a cloned meta-object * Which in turn forces a new type table (which raises a bunch of questions about what .WHAT evaluates to) * And the new type, formed per closed over set of values, will then miss on every single bit of our dynamic optimization infrastructure that keys on type (method caches, multi caches, specializations, etc.) Declaring lexical classes and roles isn't an entirely unusual practice; without some careful analysis of when we need to do the cloning, we'd end up giving programs using this pattern a huge performance regression. All to give other programs a feature that will be hard to optimize, and so will then get a (deserved) reputation for being slow and thus probably not used all that much anyway. Show quoted text
> But I’ll settle for a warning / exceptione :-)
I think these options are worth consideration. I can't think of a false positive off hand. /jnthn
Subject: Re: [perl #130965] [LTA] `but role { ... }` interacts strangely with outer lexicals, and doesn't warn about it
From: Timo Paulssen <timo [...] wakelift.de>
To: perl6-compiler [...] perl.org
Date: Thu, 16 Mar 2017 17:57:46 +0100
Download (untitled) / with headers
text/plain 491b
On 09/03/17 20:38, jnthn@jnthn.net via RT wrote: Show quoted text
> On Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote:
>> But I’ll settle for a warning / exceptione :-)
> I think these options are worth consideration. I can't think of a false positive off hand.
class Test { method tester { say "testest" } } # warning: you're not allowed to close over variable &say! is there a sane heuristic for this? "does it have a & sigil" isn't sane, IMO, and neither is "does it come from the core setting?".
Date: Mon, 28 Aug 2017 13:22:07 -0700
To: rakudobug [...] perl.org
Subject: [BUG] mixin thread safety
From: "J . David Lowe" <j.david.lowe [...] apple.com>
Download (untitled) / with headers
text/plain 1024b
This short program behaves dies on my system, apparently because the mixed-in attribute is somehow "leaking" between the two threads (???): ``` #!/usr/bin/env perl6 await((^2).map: { start { for (^10) -> $i { my $x = Str.new but role { has $.test = $i }; die "$i != " ~ $x.test unless $x.test == $i; } } }); ``` produces output like: ``` $ ./bug Tried to get the result of a broken Promise in block <unit> at ./bug line 3 Original exception: 1 != 2 in block at ./bug line 7 $ ./bug Tried to get the result of a broken Promise in block <unit> at ./bug line 3 Original exception: 3 != 4 in block at ./bug line 7 ``` It's possible that what I'm doing in this code isn't *intended* to be thread-safe, but if that's the case, I don't understand why (e.g. looking at the code, the two threads appear to be completely isolated.) More information: ``` $ perl6 --version This is Rakudo version 2017.07 built on MoarVM version 2017.07 implementing Perl 6.c. ```
Download (untitled) / with headers
text/plain 220b
@David I think this is not a thread safety issue, but rather a result of `role`s (intentionally) not being closures. I.e. a duplicate of this RT: This is a duplicate of https://rt.perl.org/Ticket/Display.html?id=130965
From: "J . David Lowe" <j.david.lowe [...] apple.com>
Subject: Re: [perl #131983] [BUG] mixin thread safety
Date: Tue, 29 Aug 2017 09:54:47 -0700
To: perl6-bugs-followup [...] perl.org
Download (untitled) / with headers
text/plain 713b
Agreed. In that case, the threads are just racing to observe a mutating value while it's in the "expected" state. I will add my voice to the chorus calling for either making roles into closures, or producing a compile-time warning or error. It's tempting to use roles to "monkey patch", and would be good to be warned if it isn't a safe thing to do. I'm fine with closing this as a duplicate. Show quoted text
> On Aug 29, 2017, at 7:32 AM, Sam S. via RT <perl6-bugs-followup@perl.org> wrote: > > @David > > I think this is not a thread safety issue, but rather a result of `role`s (intentionally) not being closures. > > I.e. a duplicate of this RT: This is a duplicate of https://rt.perl.org/Ticket/Display.html?id=130965


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