Re: RFC 136 (v1) Implementation of hash iterators

2000-08-24 Thread Jeremy Howard
Dan Sugalski wrote: > Plus I can see each being used more often if we extend it to be valid for > sparse arrays, or used more under the hood with iterators and lazy lists > and suchlike things. Each, when used on a sparse array, would presumably > return a list of offset/value pairs of valid entri

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 01:49 PM 8/23/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: At 11:30 AM 8/23/00 -0700, Larry Wall wrote: >: >Dan Sugalski writes: >: >: I have had the "Well, Duh!" flash, though, and now do realize that having >: >: multiple iterators over a hash or array simultaneously could be rather >

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Chaim Frenkel
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Dan Sugalski writes: LW> : I have had the "Well, Duh!" flash, though, and now do realize that having LW> : multiple iterators over a hash or array simultaneously could be rather handy. LW> You can also have the opposite "Well, Duh!" flash

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Chaim Frenkel
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: DLN> Dan Sugalski wrote: >> >> Any variable that has a 'per-thread' component should be self-contained. >> >> Dan DLN> We don't know how many instances of iteration happening in the DLN> program there will be, or how many there can be.

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Tom Hughes
In message <[EMAIL PROTECTED]> Larry Wall <[EMAIL PROTECTED]> wrote: > Dan Sugalski writes: > > : I have had the "Well, Duh!" flash, though, and now do realize that having > : multiple iterators over a hash or array simultaneously could be rather > : handy. > > You can also have the opp

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Larry Wall
Dan Sugalski writes: : At 11:30 AM 8/23/00 -0700, Larry Wall wrote: : >Dan Sugalski writes: : >: I have had the "Well, Duh!" flash, though, and now do realize that having : >: multiple iterators over a hash or array simultaneously could be rather : >handy. : > : >You can also have the opposite "W

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 11:30 AM 8/23/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: I have had the "Well, Duh!" flash, though, and now do realize that having >: multiple iterators over a hash or array simultaneously could be rather >handy. > >You can also have the opposite "Well, Duh!" flash and realize that m

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Larry Wall
Dan Sugalski writes: : I have had the "Well, Duh!" flash, though, and now do realize that having : multiple iterators over a hash or array simultaneously could be rather handy. You can also have the opposite "Well, Duh!" flash and realize that most DBM implementations only support a single itera

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 12:23 AM 8/23/00 +, David L. Nicol wrote: >Dan Sugalski wrote: > > > > > Any variable that has a 'per-thread' component should be self-contained. > >We don't know how many instances of iteration happening in the >program there will be, or how many there can be. If each instance >of hash it

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Tom Hughes
In message <2823054734$[EMAIL PROTECTED]> Uri Guttman <[EMAIL PROTECTED]> wrote: > what happens if you modify the hash when you have an iterator? also we > have to require the iteration order to be fixed for a given hash which > is not modified so slices and such will remain synchro

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread Uri Guttman
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: DLN> "David L. Nicol" wrote: >> > In perl 6 the keys and values functions should no longer use the >> > same iterator as the each function - each use of keys and values >> > should use it's own private iterator instead. DLN> we

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread David L. Nicol
Dan Sugalski wrote: > > Any variable that has a 'per-thread' component should be self-contained. > > Dan We don't know how many instances of iteration happening in the program there will be, or how many there can be. If each instance of hash iteration

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread Dan Sugalski
On Tue, 22 Aug 2000, David L. Nicol wrote: > > > we could put it in a variable associated with the instance of the > > keyword. An associative array of threads to current-values. > > or in the "global per-thread data area" keyed to some immutable-during-the-run > value. Or, since shared varia

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread David L. Nicol
> we could put it in a variable associated with the instance of the > keyword. An associative array of threads to current-values. or in the "global per-thread data area" keyed to some immutable-during-the-run value. -- David Nicol 816.235.1187 [EMAIL PROTECTED]

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread Tom Hughes
In message <[EMAIL PROTECTED]> "David L. Nicol" <[EMAIL PROTECTED]> wrote: > "David L. Nicol" wrote: > > > > In perl 6 the keys and values functions should no longer use the > > > same iterator as the each function - each use of keys and values > > > should use it's own private iterator

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread David L. Nicol
"David L. Nicol" wrote: > > > > > In perl 6 the keys and values functions should no longer use the > > same iterator as the each function - each use of keys and values > > should use it's own private iterator instead. we could put it in a variable associated with the instance of the keyword. An

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread David L. Nicol
> > In perl 6 the keys and values functions should no longer use the > same iterator as the each function - each use of keys and values > should use it's own private iterator instead. And a separate one for each thread, too -- can't forget that --