In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>
> TH> Well if we allow value changes in the middle of iterating either
> TH> keys or values then that is a user visible behaviour change which
> TH> potential
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>> The only real issue is if the change effects the iterator order. Changes
>> to values should be allowed without out any adverse effects.
TH> Well if we allow value changes in the middle of iterating either
TH> keys or values then that is a
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I'd rather not have the expansion performed. Some other mechanism, either
> under the covers or perhaps even specified in the language.
Absolutely. Both mechanisms have been suggested - my under the
covers proposal
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I wasn't just talking about the threaded case though - the point
TH> which I was making was that of what happens if a single threaded
TH> program alters a hash in the middle of iterating it.
TH> Currently keys and values are flattened when
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> Why not
> lock(%y);
> foreach my $x (keys %y) {
> $y{$x+1} = 1;
> }
> unlock(%y);
>
> Hmm, I just realized, perhaps we can just punt. Any p5 program that
> doesn't use Threads
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I guess we can translate all uses of keys and values when doing
TH> the p52p6 conversion - so that this:
TH> foreach my $x (keys %y)
TH> {
TH> $y{$x+1} = 1;
TH> }
TH> becomes:
TH> foreach my $x (@temp = keys %y)
TH> {
TH>
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We punt. If the programmer wants consistent data in a multithreaded
> program, he or she needs to lock the hash down. I'm all up for the
> iterators looking at the hash as it exists--if the programmer wants
> a snaps
At 05:17 PM 9/5/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> This could be a lot more efficient than modifying the vtbl and filling
> >> up the stack with the keys. I really am suspicious of replacing the
> >> vtbl entry, there may be more than one
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Or have a "next" vtable function that takes a token and returns the next
> entry in the variable. Each iterator keeps its own "current token" and the
> variable's just responsible for figuring out what should get r
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> This could be a lot more efficient than modifying the vtbl and filling
>> up the stack with the keys. I really am suspicious of replacing the
>> vtbl entry, there may be more than one thread working its way through
>> the hash.
DS> Or hav
At 08:18 PM 9/4/00 -0400, Chaim Frenkel wrote:
> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
>
>PRL> =head2 Freezing state for keys and values efficiently
>
>PRL> I believe this problem can be solved by using the vtable for the
>PRL> hash to wrap any mutating functions with a co
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =head2 Freezing state for keys and values efficiently
PRL> I believe this problem can be solved by using the vtable for the
PRL> hash to wrap any mutating functions with a completion routine that
PRL> will advance the iterator t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implementation of hash iterators
=head1 VERSION
Maintainer: Tom Hughes <[EMAIL PROTECTED]>
Date: 20 Aug 2000
Last Modified: 4 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 136
St
13 matches
Mail list logo
