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
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
>
> "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
> "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.
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
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
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
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
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
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
> "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
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
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
> 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]
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
"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
>
> 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 --
17 matches
Mail list logo