From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 19:22:49 -0500
On Sat, Jul 12, 2008 at 01:11:12AM +0200, Jonathan Worthington wrote:
> This is consistent with my view of the specified Perl 6 semantics[1] for
> closure handling. I translated Bob's Perl 5 example into PIR and put
> newclosure where the Perl 6 specification would suggest to put it and it
> produces the same output as the Perl 5 script. This is without doing
> *any* newclosure calls prior to a call, just some when we are taking a
> reference.
>
> Pm: I hope the PIR helps you understand Bob's example better. Notice
> that we do newclosure whenever a block is referenced (where by block I
> mean anything compiled down to a Parrot .sub) and the reference contains
> the new closure, which makes sense because we're taking a closure
> (recording a snapshot of it at that point) to invoke later.
Yes, the translation helps a lot. But what you came up with is
almost exactly what I would expect PCT/Rakudo to be generating
_now_ for this code example (modulo a few minor details).
That is good to hear. (But, of course, the devil . . . )
So I'm still left without a good PIR counterexample that shows that
PCT as presently designed will generate code that won't work. :-(
If you always do "newclosure" for lexical subs, then you're probably
safe. But any "spectest" failures that involve closures within
recursive subs should be considered candidates (but you say below you
don't have any).
================
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 21:03:10 -0500
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.
Then PCT may have a problem. Unfortunately, I'm not sure how to produce
a useful Rakudo test case.
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.
Assignment seems to do assign_pmc, which for a closure invokes the Sub
method (there is no Closure method). Needless to say, Sub:assign_pmc
does nothing special to capture the current context; if that is NULL,
then "autoclose" takes over when the thing is called. There probably
should be a Closure:assign_pmc method that does most of what
parrot_new_closure (src/sub.c:506) does, as this is the guts of the
C<newclosure> op. (And the current lack of Closure:assign_pmc or
Closure:clone looks like it leaves dangling context refs.)
> >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 . . .
Given that r28763 passed the Parrot test suite, that may not be too
surprising. I've found a number of interesting Parrot bugs from
cut-and-pasting large chunks of the CMUCL implementation into Kea-CL.
Most involve combinations of Parrot features that people coding tests
for Feature X are not likely to think of. (If you encounter a big, ugly
test with my fingerprints on it, that's probably one of them.)
-- Bob
