From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 13 Jul 2008 23:31:49 -0400
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 01:27:29 -0400
Oops; r28763 seems to be the source of one of my problems, a "lexical
not found" error. With this change, Parrot gets
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 01:27:29 -0400
Oops; r28763 seems to be the source of one of my problems, a "lexical
not found" error. With this change, Parrot gets confused when multiple
calls to the :outer sub have been made, such as when it is recursiv
On Sat, Jul 12, 2008 at 08:47:32PM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > > > Short answer: cloning i
On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > > Short answer: cloning is what will enable the following to work:
> > >
> > > for 1..10 -> $x {
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 16:46:19 -0400
. . . I will add [recursive-lex.pir] as a "todo" case, so we can be
sure that *that* also continues to work.
As promised, with badlex.pir and Jonathan's PIR case.
-- Bob
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Sat, 12 Jul 2008 10:06:33 -0500
On Sat, Jul 12, 2008 at 12:30:02AM -0400, Bob Rogers wrote:
> (And I still don't understand the *point* of cloning a closure.)
. . .
Longer answer: Assume under my proposal that we don't have
On Saturday 12 July 2008 01:07:20 chromatic wrote:
> Obviously all Closures need valid captured contexts, but we have a big
> problem when attempting to invoke a named Closure before attaching its
> captured context. In Perl 5 terms, this is the relevant code:
>
> {
> my $
On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
>
> > Short answer: cloning is what will enable the following to work:
> >
> > for 1..10 -> $x {
> > sub foo() { say $x; }
> > push(@foos, &foo);
> > }
On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> Short answer: cloning is what will enable the following to work:
>
> for 1..10 -> $x {
> sub foo() { say $x; }
> push(@foos, &foo);
> }
Is that really valid Perl 6 code? I can see "my sub foo" working there, b
On Sat, Jul 12, 2008 at 12:30:02AM -0400, Bob Rogers wrote:
> ... But, as I quoted you:
>
> . . . if cloning works the same as newclosure than we don't need
> an explicit newclosure . . .
>
> Which seems to say something entirely different. So I thought I should
> point out that clon
On Sat, Jul 12, 2008 at 01:07:20AM -0700, chromatic wrote:
> > And again, under my proposal I've been saying (apparently
> > ineffectively) that "autoclose" would be gone entirely, and
> > invoking a Closure that hasn't already had its context captured
> > (i.e, outer_ctx is NULL) will throw an exc
On Friday 11 July 2008 20:59:05 Patrick R. Michaud wrote:
> You're _completely_ missing my point. If we follow my proposal
> to modify Parrot or code generation such that a capture operation
> is performed for closures at the beginning of every outer sub
> invocation, then by the time we get to a
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 22:59:05 -0500
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote:
>Of course, if cloning works the same as newclosure than we don't
>need an explicit newclosure for the examples given, beca
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote:
>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 clos
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 21:55:41 -0500
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anyt
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 exampl
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anything
> newclosure might have done. If you meant "have its outer_ctx set
> I whenever an outer sub is
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 16:23:28 -0500
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
>Based on what Bob has been saying, I can't now think of a case where
>an inner closure _shouldn't_ go ahead and have its outer_ct
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 Raku
Patrick R. Michaud wrote:
Yes, the translation helps a lot.
OK, good.
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).
I tried to write it so it wouldn't be far off what Rakudo would produce
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
> pro
Hi all,
Patrick R. Michaud wrote:
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
This is certainly not the case for recursive subs. Consider the
attached example, a lightweight Perl 5 dumper. (It is slightly
artificial to break the rec
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
>This is certainly not the case for recursive subs. Consider the
> attached example, a lightweight Perl 5 dumper. (It is slightly
> artificial to break the recursive step out into a sub, but tha
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
>Based on what Bob has been saying, I can't now think of a case where
>an inner closure _shouldn't_ go ahead and have its outer_ctx set
>whenever an outer sub is invoked . . .
>
> Foul! That's exactly what r28763 does to break
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 01:55:11 -0500
On Thu, Jul 10, 2008 at 11:06:55PM -0500, Patrick R. Michaud wrote:
>
> I _think_ [methods and subs] are the only two cases where we
> have to do something like this, and I guess they aren't to
On Thu, Jul 10, 2008 at 11:06:55PM -0500, Patrick R. Michaud wrote:
>
> I _think_ [methods and subs] are the only two cases where we
> have to do something like this, and I guess they aren't too onerous.
I was wrong, the third case is MultiSubs, and at the moment
it's _very_ onerous, because w
On Thu, Jul 10, 2008 at 11:23:03PM -0400, Bob Rogers wrote:
>All I'm really wanting to know is what
>PIR the compilers and tools should be emitting for these very
>common Perl 6 constructs, and to have that PIR work in Parrot.
>
> Seriously, though, I've been wanting to learn more abou
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Thu, 10 Jul 2008 21:51:40 -0500
On Thu, Jul 10, 2008 at 09:35:29PM -0400, Bob Rogers wrote:
. . .
> [...] However, if some
> or all of these references were "downward" (i.e. not referenced after
> the containing block retur
On Thu, Jul 10, 2008 at 09:51:40PM -0500, Patrick R. Michaud wrote:
> Perl 6 disallows having multiple subs of the same
> name unless they are explicitly declared 'multi' or
> the later subs provide the "is instead" trait [1].
Oops, I cut off the reference while sending:
[1] http://dev.perl.org/p
On Thu, Jul 10, 2008 at 09:35:29PM -0400, Bob Rogers wrote:
> Hmm. I have been assuming that when you say "taking a closure", that is
> equivalent to "using *the* closure" for a given :outer context. It's
> beginning to dawn on me that this might not be what you mean; more
> below.
I think I'm n
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Thu, 10 Jul 2008 00:31:53 -0500
On Thu, Jul 10, 2008 at 12:29:57AM -0400, Bob Rogers wrote:
. . .
> Shouldn't
>for 1..10 -> $x {
> sub foo() { say $x; }
> push(@foos, \&foo);
>}
> produce the sam
On Thu, Jul 10, 2008 at 12:29:57AM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 18:49:53 -0500
>
>On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>> Not true. The compiler always knows when it's compiling a closure. S
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 18:49:53 -0500
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
> Not true. The compiler always knows when it's compiling a closure. So
> if, at the point of definition, the emitted code does:
>
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
Content-Description: message body text
>In effect this is little different from having 'foo' as an immediate
>block. If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subrou
On Wed, Jul 09, 2008 at 03:45:31PM -0700, chromatic wrote:
>
> That example is fine with me. I almost deleted all of the hijinks necessary
> in Closure PMC to attach to a never-initialized outer lexical scope before I
> read the lexical spec again and realized that someone designed it that way.
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>...
>If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subroutine has to be generated as:
>.local pmc $P0
>
On Wednesday 09 July 2008 15:37:51 Bob Rogers wrote:
>I suspect the motivation for the bizarreness of the specification is the
>desire to make code like this work in Parrot:
>
> {
> my $x;
>
> sub set_x { $x = shift }
> sub get_x
From: chromatic <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 13:59:16 -0700
I read that in the lexicals PDD, and I think the current behavior is
bizarre *without* the call to newclosure. How is it even possible to
close over a lexical environment in an outer when that lexical
envir
On Wednesday 09 July 2008 13:46:19 Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 08:25:52 -0500
>If I understand what you're saying, and then take it to what I see
>as its ultimate conclusion, you're basically claiming that every
>cal
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 08:25:52 -0500
On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
> What "foo" should do is create a closure and call that:
>
>.const .Sub inner = 'inner'
>inner = newclosure inner
>i
[typo clarification]
On Wed, Jul 09, 2008 at 08:25:52AM -0500, Patrick R. Michaud wrote:
> [...] If we now say that a newclosure op is required to invoke 'foo',
> then that means that the 'foo()' HLL subroutine has to be generated as:
>
> .local pmc $P0
> $P0 = find_name_not_null 'foo'
On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
>What "foo" should do is create a closure and call that:
>
> .const .Sub inner = 'inner'
> inner = newclosure inner
> inner()
If I understand what you're saying, and then take it to what I see
as its ultimate conclu
From: "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]>
Date: Fri, 27 Jun 2008 16:12:13 -0700
Fixed in r28763.
Thanks,
Jonathan
Oops; r28763 seems to be the source of one of my problems, a "lexical
not found" error. With this change, Parrot gets confused when multiple
calls to the
Fixed in r28763.
Thanks,
Jonathan
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56398]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56398 >
Earlier today Jonathan was able to implement the :lexid proposal
discussed in RT#5
45 matches
Mail list logo
