In a message dated Mon, 19 Apr 2004, Larry Wall writes:
> On Mon, Apr 19, 2004 at 04:48:05AM -0600, Luke Palmer wrote:
> : Trey Harris writes:
> : > Can anyone explain the rules of placeholder attachment? i.e., in the
> : > example in Perl6::Placeholder's manpage,
> : >
> : > grep { $data{$^value} } 1..10;
> [...]
> : In your first example, it does what you mean because the hash subscript
> : isn't a closure. Curlies are always closures, except when they're not
> : (to be specific, in hash subscripts and hash constructors).
>
> Yes, that's the basic rule. In Perl 5 the curlies are (potentially)
> blocks, though the optimizer throws away the block entry and exit
> when it thinks it can. In Perl 6 we'll just say that those aren't
> blocks. If you really want a block inside a subscript, you can always
> use do {}. (But merely putting semicolons inside a subscript turns
> it into a multidimensional subscript, not a block.)
Okay, thanks for setting me straight there.
> : > It's easy to just say "don't nest placeholder-using closures," but that
> : > doesn't seem workable in practice since every block is a closure, unless
> : > placeholders are forbidden from all but the most trivial cases. Absurdly
> : > trivial, it seems. How about
> : >
> : > $sub = { if $^a { $^b = $^a } };
> :
> : I want this to work. It could look at C<if>'s signature and see that
> : the closure it is expecting wants arguments, and since it doesn't, it
> : knows that they belong outside. But that doesn't generalize.
>
> I don't think I want that to work.
Alright, you're the boss. But it does make placeholders nearly useless,
does it not, by essentially limiting them to subs containing single
expressions?
> : I think a better solution would be to associate all placeholders with
> : the outermost closure that introduced a placeholder. For example:
> :
> : $sub = { { $^a + $^b } };
> :
> : Would bind them both to the inner one, while:
> :
> : $sub = { $^a; { $^a + $^b } };
> :
> : Would bind them both to the outer one.
>
> This is the sort of twisty thinking that some people can keep straight
> and some people can't. That's why we simplified the list of rules
> from the original placeholder RFC, after all.
What is the list of rules? That's why I asked, and I'm still not clear
exactly what happens in the example I gave. Saying that my example
shouldn't work only eliminates one of the possibilities, the one where it
works, while leaving all the ways it might not work open. It being
guaranteed to do what I don't mean is a step towards making what I mean be
something closer to what it does, but it would be helpful if I knew what
it does so that I can more finely adjust what I mean. :-)
Trey
