OK I think I''m getting it.

You seem to have introduced the ability to use a statement rather than a block in these constructs. E.g. try blahblah;


Is that in general?

So the statements needs to be closure-block-like, even though braces are not written, so anything that depends on it being an inner block is illegal. So if blahblah was a macro that wanted to, say, "ïmport" something into the current scope in the manner of a "my" declaration, it should be able to sense that its current context is not real but one of these thunks; depending on the nature of the macro it needs to know to navigate to the correct ::MY context or emit an error.

Perhaps code in such a situation that accesses ::MY etc. should see it invisibly redirected to the proper lexical scope but readonly.

The behavior needs to be well-specified so that code will mean the same thing if executed on an implementation that actually generated block-like thunks or one that used machine level goto instructions to jump around the conditional code without changing contexts.

--John

Larry Wall larry-at-wall.org |Perl 6| wrote:
On Thu, Jul 31, 2008 at 05:56:14AM -0500, John M. Dlugosz wrote:
In S04, "Other similar Code-only forms ..."
What does that mean?

It is feebly attempting to say that, because these are control flow
functions, the argument is really a thunk that the function has
control of when and how it's executed, much like in the constructs:

    $x && thunk
    $x || thunk
    $x ?? thunk !! thunk

It's also basically claiming that thunks have dynamic scope without
lexical scope.  That is, if you said "my $x" in such a thunk it would
propagate to the lexical scope of the statement, but a temp would
presumably not.  But arguably the proper thing would be to outlaw
lexically scoped declarations entirely in such a conditional thunk,
akin to the P5.10 restriction on

    my $x = 1 if 0;

Larry


Reply via email to