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 BLO
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
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
>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
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
>>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 out if a retval
isn't wanted (as i
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 a
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; .
Perl6 RFC Librarian wrote:
> =head2 Each thread gets its own copy of block-scoped lexicals upon
> execution of C
>
> Example 8
>
> #!/my/path/to/perl
> foo();
> Thread->new(\&foo);
>
> sub foo
> {
> my $a = 1;
> print $a++;
> }
[prints "11"]
This must b
Jonathan Scott Duff writes:
> 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?
Well, I suppose that for consistency's sake they shou
On Thu, Aug 31, 2000 at 02:13:23PM -0500, Christopher J. Madsen wrote:
> Jonathan Scott Duff writes:
> >do { ... last; ... }; # exit the block immediately
> >do { ... next; ... }; # equivalent to last?
> >do { ... redo; ... }; #
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 t
>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.
But I while I am not completely bothered by letting the value
dangle here:
($msg, $defs
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
> 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
At 02:30 PM 8/31/00 -0500, Christopher J. Madsen wrote:
>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;
> >
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'
>AFAICT we could make it a syntax error iff foo is not used in void context;
>Perl must be able to tell whether or not it is used in order to know what
>context the result is in, right?
Well, that depends. Often you must delay till run-time. When Perl
simply sees something like:
sub fn {
>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 bu
Tom Christiansen writes:
> >Yes, but 'eval' has the semantics "run this code but don't let it play
> >any funny tricks on me, like dying or anything", where 'do {...} while'
> >has the semantics "a while loop that evaluates its condition at the
> >end". There's no obvious reason why 'return'
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> It just kinda irks me here:
TC> $total += 2 * do {
TC> my $count = 0;
TC> for $n (@nums) { $count += $n }
TC> $count;
TC> };
TC> I rather that were:
TC> $total += 2 * do {
TC> my $count = 0;
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 ABSTR
> Steven W McDougall wrote:
> > > 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 o
>
> 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 { ... };
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> critical { ... }; # one thread at a time in this block
>
> =item C BLOCK
>
> Executes BLOCK in a separate thread. Syntactically, C BLOCK
> works
[cc'd to internals to check a possible performance problem.]
Steven W McDougall wrote:
> > 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($f
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.
27 matches
Mail list logo
