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

Reply via email to