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
