On 29 Oct 2002, Marco Baringer wrote:
: 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'?
I don't like adding another keyword. But...
: 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.
We could make "return" a method as well as a built-in sub. That gives us
Loop.return($x)
Sub.return($x)
Topic.return($x)
Thread.return($x)
Block.return($x)
There.return($x)
or
return Loop: $x
return Sub: $x
return Topic: $x
return Thread: $x
return Block: $x
return There: $x
BLOCK_NAME could come in under a rule that says that if the classname lookup
on an identifier fails, and there's an outer labeled scope of that name,
it is treated as a reference to that object. Otherwise it's an error,
since we don't do barewords anymore.
I suppose a case could be made that the innermost block scope is
really named MY, not Block. So it could be MY.return($x).
If the method is named "return" however, we might run into ambiguity with
return $x;
depending on whether we think that ought to try looking for a $x.return.
It could be argued, for instance, that
close $x;
is really
$x.close;
Maybe it only does that if there's no close function defined.
: 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?
Lots. There's just been too few decisions. :-)
Or too many, depending on how you look at it...
: how about:
:
: { BLOCK_NAME: ... }
Hard to distinguish from a label inside the block.
: 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.
Other than that people think of it that way...
: 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...
Both of those suffer from run-time-itis. A compile-time solution is
needed. Without invoking any new syntax, we could do something with an
inner property block:
{ NAME { "BLOCK_NAME" }
...
if $cond {
return BLOCK_NAME: $foo;
}
}
But that's a little bit ugly. Well, maybe more than a little bit...
On the other hand,
{
...
if $cond {
return BLOCK_NAME: $foo;
}
} is named("BLOCK_NAME")
could conceivably work at compile time but doesn't pass the test that
people prefer to name things at the beginning. So we could end up with
some kind of syntax like:
{ is named("BLOCK_NAME")
...
if $cond {
return BLOCK_NAME: $foo;
}
}
or maybe
{:BLOCK_NAME
...
if $cond {
return BLOCK_NAME: $foo;
}
}
for short.
Or maybe we can just stick with a rule that says that any block
within a labeled statement thinks of itself as having that label.
Then we're back to:
BLOCK_NAME:
mumble $fritz {
...
if $cond {
return BLOCK_NAME: $foo;
}
}
jumble $spritz {
...
if $cond {
return BLOCK_NAME: $foo;
}
}
tumble {
...
if $cond {
return BLOCK_NAME: $foo;
}
}
which at least keeps us from having to name each block independently.
It also has the benefit of working like Perl 5 programmers expect.
For which there's something to be said...
Larry
