Re: labeled if blocks
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)
Re: labeled if blocks
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 Creturn 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
Re: labeled if blocks
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
--- Larry Wall [EMAIL PROTECTED] wrote:
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 Creturn 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
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: labeled if blocks
From: Larry Wall [EMAIL PROTECTED]
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
RE: labeled if blocks
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 Clast 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 [EMAIL PROTECTED]
@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)
Re: labeled if blocks
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
Fwd: Re: labeled if blocks
Sorry, forgot to hit reply-all.
--- Austin Hastings [EMAIL PROTECTED] wrote:
Date: Mon, 28 Oct 2002 12:58:16 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
Subject: Re: labeled if blocks
To: Larry Wall [EMAIL PROTECTED]
--- Larry Wall [EMAIL PROTECTED] wrote:
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).
I've always hated that paradigm. But you're right. Threads need exit
codes, too.
leave thread result (0 but true);
: 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.
How do you leave a topic without also leaving the block wrapping it?
Will there be a resume topic?
with $x - {
...
leave topic;
print $_;
resume topic $x;
...
}
Can the perl-poets count on off as a synonym for leave?
...
$luser.sendmail($flame) if off topic; # :-p
...
: last - leave block
That's leave loop, I expect.
How to differentiate? As far as I can tell, the only value in
discriminating among leave topic, leave block, and leave loop
is
to save putting a label on the containing curly.
This may be value enough.
How likely is this to be useful in an anoynmous programming
context,
such as a filter, where the containing structures are not known to
the
code author? (IOW: If I want to write a break_loop verb, being able
to say leave loop is really valuable.)
What I'm thinking of as ret is:
ret leave block
ret $x leave block, $x
I like the comma, if result is a synonym for whitespace:
leave block, result $x;
Which extends to longjmp:
leave $jb, result $x; # AKA leave $jb, $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)
leave result $x; # Scans okay.
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.
Not me. leave changes stack frame, ret pops. Plus, ret doesn't scan
for
loop control and stuff.
Or maybe it should be *val.
Except that val($x) could be misread as setting the
value without returning...
I agree with the exception. val sounds like a prelude to 0 but
true
from a distance. (Kind of like Pascal's automatic creation of a
variable with the same name as all functions:
fibonacci := 1; # val(1);
: 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.
Just you wait. EmbeddedPerl is coming. :-O
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.
Hmm. So perhaps leaving is a superoperation of throwing. That is
to
say, throw takes a value and carries it upstack until a
smartmatching
catch block is found, evaluating finally clauses all the while.
And leave takes a value and a frametype and carries it upstack
until a matching frametype is found.
So a throw is just a leave with a frametype of a sub that looks at
the stack/block/topic frame and tries to smartmatch catch-blocks?
Yikes!
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
Re: labeled if blocks
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
Re: labeled if blocks
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
Re: labeled if blocks
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
Re: labeled if blocks
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 Creturn 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
- Cloop - innermost while/for/foreach
- Csub - current sub
- Ctopic - innermost topicalizer
- Cthread - exit
- Cblock - innermost block
- Cthere - (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 Creturn; does under perl5, so
perl6's Creturn is a synonym for Creturn 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
average perl users? was: labeled if blocks
On Mon, 28 Oct 2002 at 14:50 -0800, Larry Wall [EMAIL PROTECTED] 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
Re: labeled if blocks
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 Creturn 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
: - Cloop - innermost while/for/foreach
: - Csub - current sub
: - Ctopic - innermost topicalizer
: - Cthread - exit
: - Cblock - innermost block
: - Cthere - (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 Creturn; does under perl5, so
: perl6's Creturn is a synonym for Creturn 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
Re: average perl users? was: labeled if blocks
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
RE: average perl users? was: labeled if blocks
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.
--Brent Dax [EMAIL PROTECTED]
@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)
Re: labeled if blocks
Larry Wall [EMAIL PROTECTED] 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?
Re: labeled if blocks
--
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
Re: labeled if blocks
Steve Canfield [EMAIL PROTECTED] 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
labeled if blocks
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
Re: labeled if blocks
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.
Larry
