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
