labeled if blocks

[Steve Canfield]

Will Perl6 have labeled if blocks? Like this:

BLAH:
if ($foo) {
...
last BLAH if $bar;
...
}

_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp

[Erik Steven Harrison]

--

On Sat, 26 Oct 2002 21:02:20
Larry Wall wrote:
>On Sat, 26 Oct 2002, Steve Canfield wrote:
>: Will Perl6 have labeled if blocks? Like this:

>:
>: BLAH:
>: if ($foo) {
>: ...
>: last BLAH if $bar;
>: ...

>: }
>
>I don't see why we need it offhand. But we might well have something
>that returns out of the innermost {...} anyway, so you could use that.

Well, I always thought that labeled blocks in general would give us a
way to label lexical scopes. If so, why shouldn't it apply to if
blocks?

-Erik

>
>Larry
>
>

____________________________________________________________
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus

[Marco Baringer]

"Steve Canfield" <canfie...@hotmail.com> writes:

> Will Perl6 have labeled if blocks? Like this:
>
> BLAH:
> if ($foo) {
> ...
> last BLAH if $bar;
> ...
> }

why not use -> to create a sub which you can return from?

if $foo -> {
...
return if $bar;
...
}

this of course means you can't directly return from the sub (or whatever) in
which the if (or given or while or for) is nested...

slightly related:

what happens to the return value of the subs passed to for, if, while
and given statements? (what does '$foo = if $bar { ... } else { ... }'
do?)

--
-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

[Larry Wall]

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.

: this of course means you can't directly return from the sub (or whatever) in

: which the if (or given or while or for) is nested...

Which is why the rule for "return" says there has to be a "sub",
because that's what people will usually expect "return" to do, at least
until they get sophisticated about every block being a subroutine.
And that's also why we need a different way of returning from the
innermost block (or any labelled block). "last" almost works, except
it's specific to loops, at least in Perl 5 semantics. I keep thinking
of "ret" as a little "return", but that's mostly a placeholder in
my mind. I've got a lot of those...

: slightly related:

:
: what happens to the return value of the subs passed to for, if, while
: and given statements? (what does '$foo = if $bar { ... } else { ... }'
: do?)

Same thing as in Perl 5. Try this:

print do { if (int rand 2) { "true" } else { "false" } }, "\n";

The only difference is that in Perl 6, there is no cat. :-)

Larry

[Austin Hastings]

How about "leave"?

leave
<SURROUNDING> | [<SURROUNDING>]<IDENTIFIER>
[ [result] <VALUE-SPEC> ];

Aliases:
=========
return -> "leave sub"
exit -> "leave program" (or is it "thread"?)
break -> "leave loop" (this is shaky: does it deserve to be here?)
last -> "leave block"

Extensions (these are WAY! optional):
==========================
enter $jb BLOCK;
leave $jb [result $val];

You may recognize these from a past life. But now they're like an
inversion of throw-catch/return, since the result is "left".

my $jb;

sub myoutersub()
{
...
$val = enter $jb {
mysub();
...
} if $needwork;
...
return $val;
}

sub mysub()
{
OUTER: for ...
for ...
if $foo ->
{
...
leave block if $bar; # leaves the "if" block
leave sub if $foo > 100; # returns
leave OUTER if is_prime($foo); # last OUTER if ...
}

leave $jb result 0
if $xyz; # Back to myoutersub, leaves block
}

=Austin

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

[Steve Canfield]

>From: Larry Wall <la...@wall.org>

>"last" almost works, except it's specific to loops

But last also works for anonymous blocks, which aren't loops. (Aren't they?
Don't know about you tovarisch, but my anonymous blocks execute just once.)

In fact, that's why I asked. I have a lot of code that looks like this:

FOO:
{
last FOO if $bar;
...
last FOO if $blah;
...
last FOO if $jonesie;
...

# if we get this far then we passed all the tests
...
}

That first check, where I go into a block and then exit it immediately, that
just somehow feels wrong. It feels like it oughta be an if, but then I
can't last out of the if.

_________________________________________________________________
Choose an Internet access plan right for you -- try MSN!
http://resourcecenter.msn.com/access/plans/default.asp

[Brent Dax]

Larry Wall:
# "last" almost works, except it's specific
# to loops, at least in Perl 5 semantics. I keep thinking of
# "ret" as a little "return", but that's mostly a placeholder
# in my mind. I've got a lot of those...

I don't see why C<last> has to work only on loops, or why there can't be
an alternate mode for them, or something. With named blocks, there's no
reason one of these can't work:

for @foo {
CHECK: if /^_/ {
if /^__/ {
...
last CHECK;
}
...
last;
}
}

LOOP: for @foo {
CHECK: if /^_/ {
if /^__/ {
...
last CHECK;
}
last LOOP;
}
}

# The only difference is that in Perl 6, there is no cat. :-)

Ah, I see that my diabolical scheme for World Domination is proceeding
as planned...

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

[Larry Wall]

On Mon, 28 Oct 2002, Austin Hastings wrote:
: How about "leave"?

Right, that brings back some memories.

: leave

: <SURROUNDING> | [<SURROUNDING>]<IDENTIFIER>
: [ [result] <VALUE-SPEC> ];
:
: Aliases:
: =========
: return -> "leave sub"

Right.

: exit -> "leave program" (or is it "thread"?)

Hmm. Dunno. I'll assume thread for now. At least under some
thread models, it's the main thread's exit that counts for the
program exit. But I'm not a threading expert (yet).

: break -> "leave loop" (this is shaky: does it deserve to be here?)

That's "leave switch", or "leave topic", or some such, I'd think.

: last -> "leave block"

That's "leave loop", I expect.

What I'm thinking of as "ret" is:

ret leave block
ret $x leave block, $x

One could argue that leaving the innermost block should be the
default, but that doesn't quite make "leave" a synonym for "ret".
It's one of those situations where you want to have two different
defaults in different situations. Hmm. Suppose instead of
a function, we have a method, and scope matching happens via
class just as with exceptions:

return -> Sub.leave
return $x -> Sub.leave($x)
exit -> Thread.leave
exit $x -> Thread.leave($x)
break -> Topic.leave
last -> Loop.leave
last LABEL -> Loop.leave(label => "LABEL")
ret -> Block.leave
ret $x -> Block.leave($x)

Then you could also have a global sub *leave that defaults to Block.
Then "ret" is officially unnecessary, since you could say

leave($x)

Except that "leave" doesn't read right for that--sounds like you're
wanting to "leave $x". Maybe it's

leave(value => $x)

but that's not very concise. Perhaps it doesn't matter, since
the usual way to return a value from a block looks like this:

{
...
$x;
}

But if you're gonna define a global sub anyway to default the invocant,
maybe *ret will be more meaningful to people than *leave. Or maybe it
should be *val. Except that val($x) could be misread as setting the
value without returning...

: Extensions (these are WAY! optional):

: ==========================
: enter $jb BLOCK;
: leave $jb [result $val];

I'd say those would map to

$jb.enter {...}
$jb.leave(value => $val);

presuming we wanted to get that fancy, which most of us won't.

But I do very much like the general "leave" idea. It's one of
those simplifications we're looking for. The hallmark of such
simplifications is whenever you can say "A is just a B". Here are
some from Perl 5:

An object is just a blessed referent.
A class is just a package.
A method is just a subroutine.

We're modifying those ideas a bit in Perl 6, at least to the extent
that we use different keywords, but the underlying concept is still
there. But in Perl 6 we now also have things like:

A Perl5 magic is just a property.
A Perl5 attribute is just a property.
A block is just a closure.
A control structure is just a subroutine that can call closures.
A switch is just a control structure that sets the topic.
A case is just a smartmatch against the topic.
An exception handler is just a switch with a funny topic.
An exception handler is just a closure property.
Anything like an exception handler is also just a closure property.
Control flow is just a kind of exception.
An object attribute is just an oddly scoped variable.
A class attribute is just a package or lexical variable.
A grammar is just a class.
A grammar rule is just a method.
A regex modifier is just a pragma.
A type is just a property that's interpreted as a contract.
A signature is just a way to bind a list to some names.
A vector operator is just a "hyper" scalar operator.

And maybe:

A bitwise operator is just a logic operator scoped to a set of bits.

That's why I can't accept a characterization of

+& +| +X - bitwise operations on int
+&= +|= +X=

~& ~| ~X - bitwise operations on str
~&= ~|= ~X=

?& ?| ?X - bitwise operations on booleans
?&= ?|= ?X=

as UME (Unnecessary Multiplication of Entities). The things you see
there aren't entities--rather, they're decomposable to entities that
are reused from elsewhere. The *only* new thing is the grammar rule
that says you can modify a logic operator with a context operator. I
would submit that

some_big_long_term ~| some_other_big_long_term

is much clearer than

~some_big_long_term .| ~some_other_big_long_term

because you have the same problem as when you move the parenthese out
front of the function--the context is further away. Plus we still have
to reason out what the polymorphic operator is going to do.

I do realize that every time we say "an A is just a B", it's really a
kind of fib, because they're all oversimplifications, particularly when
the concept B is more complicated than the concept A. A closure is
arguably harder to understand than a block, after all. But this is how
I think, and Perl 6 is going to be full of it, one way or another. :-)

Larry

[Angel Faus]

> And maybe:
>
> A bitwise operator is just a logic operator scoped to a set of
> bits.
>
> That's why I can't accept a characterization of
>
> +& +| +X - bitwise operations on int
> +&= +|= +X=
>
> ~& ~| ~X - bitwise operations on str
> ~&= ~|= ~X=
>
> ?& ?| ?X - bitwise operations on booleans
> ?&= ?|= ?X=
>
> as UME (Unnecessary Multiplication of Entities). The things you
> see there aren't entities--rather, they're decomposable to entities
> that are reused from elsewhere. The *only* new thing is the
> grammar rule that says you can modify a logic operator with a
> context operator. I would submit that
>
> some_big_long_term ~| some_other_big_long_term
>
> is much clearer than
>
> ~some_big_long_term .| ~some_other_big_long_term
>
> because you have the same problem as when you move the parenthese
> out front of the function--the context is further away. Plus we
> still have to reason out what the polymorphic operator is going to
> do.
>

Could we please, please, please have bitwise operators be out of the
core. We expect that they are not going to be used by the average
user, so it looks fair to apply the ultimate negative huffman
enconding: they need to be specially required.

A simple "use bitwise" would be ok. That would provide a proper
manpage to explain the meta-operators thing, and would shorten the
main list, which is something that we desperatelly need.

On other order of things: if it is about providing context to an
operation, wouldn't an adverb be more natural?

So it would be something like this:

$c = $a | $b; # superposition
$c = $a | $b : int; # integer bitwise
$c = $a | $b : str; # char bitwise
$c = $a | $b : bool; # bool bitwise

This can be expanded to other context-requiring cases:

$c = $a / $b; # float division
$c = $a / $b : int; # integer division

Admitedly, it's more verbose. But again this is Huffman encoding at
use.

Or, speaking aloud, we could move the adverb just along the operator,
tying them together visually:

$c = $a |:int $b;
$c = $a &:str $b;

But honestly, that looks weird.

-angel

[Larry Wall]

On Tue, 29 Oct 2002, Angel Faus wrote:
: Could we please, please, please have bitwise operators be out of the

: core. We expect that they are not going to be used by the average
: user, so it looks fair to apply the ultimate negative huffman
: enconding: they need to be specially required.
:
: A simple "use bitwise" would be ok. That would provide a proper
: manpage to explain the meta-operators thing, and would shorten the
: main list, which is something that we desperatelly need.

Fine by me. Could force people to declare hyper and super, for all that...

: On other order of things: if it is about providing context to an

: operation, wouldn't an adverb be more natural?
:
: So it would be something like this:
:
: $c = $a | $b; # superposition
: $c = $a | $b : int; # integer bitwise
: $c = $a | $b : str; # char bitwise
: $c = $a | $b : bool; # bool bitwise

Has the "long term" problem, not to be confused with the long-term problem...

Also has the "oh by the way" problem we're trying to get away from with
regex modifiers.

: This can be expanded to other context-requiring cases:

:
: $c = $a / $b; # float division
: $c = $a / $b : int; # integer division
:
: Admitedly, it's more verbose. But again this is Huffman encoding at
: use.

As long as we're admitting things, I'll admit that

$c = $a +/ $b; # integer division

looks pretty weird too. But in this case, the historical

$c = int($a / $b); # integer division

at least ends up with the right semantics (by accident).

: Or, speaking aloud, we could move the adverb just along the operator,

: tying them together visually:
:
: $c = $a |:int $b;
: $c = $a &:str $b;
:
: But honestly, that looks weird.

And is essentially the same thing as

$c = $a +| $b;
$c = $a ~& $b;

only with the context on the other end.

Larry

[Me]

> And that's also why we need a different way of returning from the
> innermost block (or any labelled block). "last" almost works, except
> it's specific to loops, at least in Perl 5 semantics. I keep thinking
> of "ret" as a little "return", but that's mostly a placeholder in
> my mind. I've got a lot of those...

A unary <-, as in

if $foo -> {
<- $bar
}

?

--
ralph

[Marco Baringer]

Larry Wall <la...@wall.org> 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...

[David Dyck]

On Mon, 28 Oct 2002 at 14:50 -0800, Larry Wall <la...@wall.org> wrote:

> On Tue, 29 Oct 2002, Angel Faus wrote:
> : Could we please, please, please have bitwise operators be out of the
> : core. We expect that they are not going to be used by the average
> : user, so it looks fair to apply the ultimate negative huffman
> : enconding: they need to be specially required.
> :
> : A simple "use bitwise" would be ok. That would provide a proper
> : manpage to explain the meta-operators thing, and would shorten the
> : main list, which is something that we desperatelly need.
>
> Fine by me. Could force people to declare hyper and super, for all that...

I admit that I use pack, bitwise operators, as well as 0x constants
in many of my scripts. I'm not sure what Angel means by taking
some of these things out of the core, but if my short perl5 scripts
start to grow to python length I'll have less incentive to
move in the perl6 direction. For now I'll just hope
that most of the people driving perl6 know what the average
users are going to do with perl6.

Isn't the average perl user using perl5 now?

David

[Larry Wall]

On 29 Oct 2002, Marco Baringer wrote:

: Larry Wall <la...@wall.org> 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

[Larry Wall]

On Mon, 28 Oct 2002, David Dyck wrote:
: I admit that I use pack, bitwise operators, as well as 0x constants

: in many of my scripts. I'm not sure what Angel means by taking
: some of these things out of the core, but if my short perl5 scripts
: start to grow to python length I'll have less incentive to
: move in the perl6 direction. For now I'll just hope
: that most of the people driving perl6 know what the average
: users are going to do with perl6.

I think that at the beginning, the average Perl 6 user would try to
use | and & as bitops and be shocked when they return superpositions
instead. So it might be better if they fail by default, unless we can
find a foolproof way to warn people when they use superpositional
ops to do bitops. But it's pretty hard to determine the intent of

$x |= 1;

On the other hand, people do adapt, eventually...

: Isn't the average perl user using perl5 now?

Well, sure. As of yet, Perl 6 users are in short supply. But we'd
like to change that at some point.

I really don't think there's any great danger of Perl 6 starting to
resemble Python, though. If we start to have too many things that have
to be declared in order to use advanced features like bitops, hypers,
and supers, someone enterprising person will just come up with a

use all;

Alternately, we could make that the default, and then anyone who wants
training wheels has to say something like:

use safe;
use basic;
use newbie;

I have historically preferred that approach. Certainly it's something
that could be enforced by a policy file too. An intro to programming
class is likely to have such a policy file anyway:

$ perl6
use CS_101;
if $a | $b {
Prof. Roberts says you are too stupid to use superpositions at line 2.

But I do think that superpositions will be used heavily enough in
case statements that people will get used to | not meaning bitor.

Larry

[Brent Dax]

Larry Wall:
# I have historically preferred that approach. Certainly it's
# something that could be enforced by a policy file too. An
# intro to programming class is likely to have such a policy
# file anyway:
#
# $ perl6
# use CS_101;
# if $a | $b {
# Prof. Roberts says you are too stupid to use
# superpositions at line 2.
#
# But I do think that superpositions will be used heavily
# enough in case statements that people will get used to | not
# meaning bitor.

use hints;

if $flags & ($mask1 | $mask2) {
...
}
^D
Hint: & is for superpositions--use .& for bitwise AND at - line
3.
(Add disable => 'superposition' to 'use hints' call to
disable this message.)
Hint: | is for superpositions--use .| for bitwise OR at - line
3.
(Add disable => 'superposition' to 'use hints' call to
disable this message.)
...

Just tell newbies to always 'use hints;', and they'll be fine.

[Piers Cawley]

Larry Wall <la...@wall.org> writes:
> 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;

How about, if 'caller' returns a continuation...

class Object;

method return { MY.caller.return(@_) }

--
Piers

"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?

[Bryan C. Warnock]

On Mon, 2002-10-28 at 14:41, Larry Wall wrote:
> And maybe:
>
> A bitwise operator is just a logic operator scoped to a set of bits.

Hypo-operators. :-)

--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)