The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Bart Lateur
Likely this should be an RFC. I'm too lazy to write it in that format right now, but I want to send this thing out before it slips my mind again. Somebody else may pick it up, if he or she wants it. If not, I'll eventually may have to do it myself. The articial distinction between do

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Peter Scott
At 11:38 AM 8/31/00 +0200, Bart Lateur wrote: The articial distinction between do BLOCK while condition; and EXPR while condition; should go, because the former is nothing but a subcase of the latter. Currently, the former executes the do BLOCK at least once, while the

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Nathan Torkington
I want last, next, etc. to magically work where I want them to: do { last if /booger/; ... } while ( ... ); Nat

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Tom Christiansen
I want last, next, etc. to magically work where I want them to: do { last if /booger/; ... } while ( ... ); Special cased for postfix modifiers, or generalized? If so, what's the return value? $x = TERM OP do { BLOCK } OP TERM; Actually, these are all pretty similar in

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Bart Lateur
On Thu, 31 Aug 2000 11:21:26 -0600, Tom Christiansen wrote: One could argue that do{} should take return so it might have a value, but this will definitely annoy the C programmers. So what. "Annoying" would be to have a situation that is *less* powerful in Perl than in C, not *more*. Oh, and

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Christopher J. Madsen
Tom Christiansen writes: One could argue that do{} should take return so it might have a value, but this will definitely annoy the C programmers. So what. So what is that it *already* annoys us, which is *why* we would like to last out of a do. Perhaps you should be able to last

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Jonathan Scott Duff
On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote: I too would like to see last, next, redo work with do loops. *Only* do loops or do blocks in general? And what should they do? do { ... last; ... }; # exit the block immediately do { ... next;

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Peter Scott
At 11:21 AM 8/31/00 -0600, Tom Christiansen wrote: I want last, next, etc. to magically work where I want them to: I too want last to work in do loops. do { last if /booger/; ... } while ( ... ); Special cased for postfix modifiers, or generalized? If so, what's the return

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Christopher J. Madsen
Peter Scott writes: I dunno, maybe a last in a do block whose value is used by something should be a syntax error. We're talking about code like $x += do { $y = get_num; last if $y == 99; $y } while defined $y; right? *Shudder* Yes, but we're also talking about code like

Re: RFC 178 (v1) Lightweight Threads

2000-08-31 Thread Steven W McDougall
The more interesting case is this: #!/my/path/to/perl sub foo_generator { my $a = shift; sub { print $a++ } } my $foo = foo_generator(1); $foo-(); Thread-new($foo); Is $a shared between threads or not? $a is shared between threads. The anonymous subroutine is a

Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-08-31 Thread Tom Christiansen
Tom Christiansen writes: However, I really don't want to see 'return' become a kind of 'last' for do{}. How would I return from a subroutine from within a do loop? You already can't do that (as it were) from within an eval. Yes, but 'eval' has the semantics "run this code but don't let

RFC 185 (v1) Thread Programming Model

2000-08-31 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Thread Programming Model =head1 VERSION Maintainer: Steven McDougall [EMAIL PROTECTED] Date: 31 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 185 Status: Developing =head1

Re: RFC 185 (v1) Thread Programming Model

2000-08-31 Thread Michael Maraist
use Thread; $thread = new Thread \func , @args; $thread = new Thread sub { ... }, @args; async { ... }; $result = join $thread; $thread = this Thread; @threads = all Thread; $thread1 == $thread2 and ... yield(); critical { ... }; # one thread at

Re: RFC 185 (v1) Thread Programming Model

2000-08-31 Thread James Mastros
$thread = new Thread \func , @args; $thread = new Thread sub { ... }, @args; async { ... }; $result = join $thread; critical { ... }; # one thread at a time in this block =item Casync BLOCK Executes BLOCK in a separate thread. Syntactically, Casync BLOCK works

Re: RFC 120 (v2) Implicit counter in for statements, possibly$#.

2000-08-31 Thread David L. Nicol
Chaim Frenkel wrote: This is making the index variable into an a wrapper object. No it isn't. Or at least it doesn't have to. Often there is a need to find the key an object was found in a container. More often in hashes than in arrays. And I think this discussion belongs in -data.