Larry Wall <[EMAIL PROTECTED]> writes: > On 27 Oct 2002, Marco Baringer wrote: > : why not use -> to create a sub which you can return from? > : > : if $foo -> { > : ... > : return if $bar; > : ... > : } > > Except that by the current rule you can only C<return> from something > that is declared with the word "sub". ->{...} is still just a fancy > block from that perspective.
since what we're talking about is what most people consider a return i think it would be a good idea to resue the word return (and therefore the concept) as much as possible. may i suggest 'return [VALUE] from BLOCK'? where BLOCK can be all kinds of things - C<loop> - innermost while/for/foreach - C<sub> - current sub - C<topic> - innermost topicalizer - C<thread> - exit - C<block> - innermost block - C<there> - (undocumented) intercal's come from. - BLOCK_NAME - name of lexically enclosing block. - anything else - reference to a block. this is debatable, if you're using return like this you should probably be using an exception. VALUE would default to undef (just like C<return;> does under perl5, so perl6's C<return> is a synonym for C<return undef from sub>). --- how do we give blocks names? has any thought been given to how you name blocks? how about: { BLOCK_NAME: ... } i'd like to get away from BLOCK_NAME: op { this blcok is actually named BLOCK_NAME } as i always thought that was the wrong place for the name, but there may be a reason for that which escapes me. of course, if blocks are objects and i can somehow get at the current block this should be: { Block.name = "BLOCK_NAME"; ... if $cond { return $foo from "BLOCK_NAME"; } } or (and this looks really weird): { ... if $cond { return $foo from "BLOCK_NAME"; } ... }.name("BLOCK_NAME") # maybe a semicolon too, maybe not... -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen