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

Owner: Nobody
Requestors: 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?".


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