On Sat, Jul 12, 2008 at 03:29:31AM +0200, Jonathan Worthington wrote: > But I'm not convinced that > we always take clones on referencing a block in Rakudo (OK, I've not > gone and looked, but I can't remember seeing anything that explicitly > does that, and I spend a lot of time staring at Rakudo... ;-)).
At present we do not explicitly invoke newclosure in Rakudo, no. But at one point PCT did have that capability, and I temporarily removed it while trying to get the other lexical stuff to work. (Getting basic immediate blocks to work was far more important than block references.) It's no problem for me to put it back. Of course, if cloning works the same as newclosure than we don't need an explicit newclosure for the examples given, because assignment already makes a clone. > >So I'm still left without a good PIR counterexample that shows that PCT > >as presently designed will generate code that won't work. :-( > > > Do you have any good non-PIR examples (e.g. failing stuff in Perl 6)? Or > am I missing the point (which, at 3am, is very possible...) I don't have anything at present that fails in Perl 6 for reasons I can't explain. The only closure/lexical-related thing that might be failing at the moment is taking references to closures, and I already know why that wouldn't be working (because newclosure in PCT is currently disabled). The only thing I haven't really tried is simple recursion with inner lexical blocks or taking references, other than the example that you and Bob just put together. The reason this ticket was re-opened is because Bob is encountering problems after r28763 (http://rt.perl.org/rt3/Ticket/Display.html?id=56398#txn-440920). There he provides an example "recursive-lex.pir" file that illustrates the problem he is encountering, which I will have to study a bit more closely. > >>Note that this doesn't give any great answers yet about what happens > >>when we do newclosure on a multi, but I think we can make that do > >>something sane (snapshot the lot, perhaps? Need to think about what > >>falls out of that...) > >> > >This is one of the possible advantages of the 'capture' approach > >proposed previously -- we can ensure that the capture operation > >always comes directly from the outer sub, so when iterating through > >the Closures in a MultiSub it's easy to determine which ones need > >a capture without having to chase up the caller chain for each one. > > No, no. I'm thinking if we take a reference to an undisambiguated > multi...then we have to newclosure it (clone it) as we take a > reference...well, I guess then it just populates its clone to the > closures too. But we'd not want to close non-closures, I guess. So, hmm... With the 'capture' approach, we just clone it (this happens anyway upon assignment) so everything works as expected. We also don't have to worry about closing non-closures, as their outer_sub will always be NULL and so they are never candidates for captures. Pm
