Buddha Buck wrote:
> They represent the -entire- future history of the program.
You imply that the entire current state of a program is captured
in a continuation. Is that really true? In a pure functional
language it is (side-effect free). In Perl (and Scheme) assignments
to global variables pro
"Christopher J. Madsen" wrote:
> foreach $item $index (@array) {
> print $item, " is at index ", $index, "\n";
> }
That's useful syntax, but I'd rather it mean stepping
pair-wise through @array. Then we could scan through a hash
with
foreach $key $value (%hash) { ... }
(Hashes are
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
[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
Steven W McDougall wrote:
> How do `our' and `my' control mutex locking?
I was assuming that all global (or "non-my" rather) variables would by
default be shared when using a thread-enabled perl. That seems like a
sensible default. If we're going to require the :shared modifier, then
ignore my co
Steven W McDougall wrote:
> Question: Can the interpreter determine when a variable becomes
> shared?
>
> Answer: No. Then neglecting to put a :shared attribute on a shared
> variable will crash the interpreter. This doesn't seem very Perlish.
If the variable isn't :shared then how can it be sha
