On Wed, Nov 20, 2002 at 04:20:07PM -0600, Me wrote:
: > $_ = 1; mumble { $_ = 2 }; print;
: >
: > will print 1 or 2?
:
: Least surprise, visually, is obviously 2.
:
: This would be true if bare blocks (even
: those passed as args) just pick up from
: the surrounding lexical context. And if
: that were true, mumble presumably could
: not do anything about this (without some
: as yet undefined language support).
Yes, that's the problem. A bare block would have to notice at run
time that it was called with unexpected arguments and unbind its
binding to the outer $_. That's probably not gonna fly.
: What does this mean:
:
: $_ = 1; mumble -> { $_ = 2 }; print;
:
: perhaps the '->' could imply that $_ /is/
: going to be private to the block somehow?
As it stands now, explicitly telling it there are no arguments would
have exactly the opposite effect, and bind $_ to the outer $_.
: Could mumble somehow be a continuation that
: alternated between generating values to be
: plugged in to the block and executing it?
Well, sure, doesn't need to be a continuation for that. Doesn't
even need to be a coroutine unless you plan to get the values one
by one.
: > sub mumble (&block) {
: > block()
: > }
: >
: > Oddly, if we make the first argument the
: > topic by default, the second block actually
: > gets &block as its topic. That's...strange.
:
: This would go away with the above scenario.
True, but I think C<mumble> has to be able to wrap its own idea of $_
around the block at compile time somehow. Perhaps we need to distinguish
the type of a "thunk" from a "sub" in the signature of C<mumble>.
sub mumble1 (Sub &block) { block($curtopic) }
sub mumble2 (Block &block) { block() }
Then
mumble1 { ... }
would compile to
mumble1 -> $_ { ... }
while
mumble2 { ... }
would compile to
mumble2 -> { ... }
forcing $_ to bind outward like a closure.
Possibly those are declared
sub mumble1 (&block(Scalar)) { block($curtopic) }
sub mumble2 (&block) { block() }
since code blocks are essentially typed by their signatures.
Larry
