tie %h A_DATABASE_RETURNING_OBJECTS, yadda, yadda, yadda;
for (grep {$h{$_}->STATE eq 'NY'} keys %h){
$h{$_}->send_advertisement();
};
We want "keys" to return an RFC24 "lazy list" when it is
compiler-obvious that it is safe to do so, meaning:
---> the argument hash is never part of an L-value within
the scope where the return value will be used
---> the context is marked as accepting lazy lists
---> more? Neverpart of an L-value within a side effect...
---> the hash is marked iterator-safe, meaning that it is
not vulnerable to deadlocks during iteration.
The question is, how do we tell the compiler that "for" in this
example requires a complete list, because the C<send_advertisement>
method changes the value of its instance?
Do all class methods start marking themselves as to whether they
change their obejcts or not? This seems too complex.
What if adding laziness to a list context was up to the programmer
and passed through functions that can support it:
for (lazy(grep {$h{$_}->STATE eq 'NY'} keys %h)){
$h{$_}->send_advertisement();
};
would cause a lazy list is passed to C<for>, and increment of
the object's "letters_sent_total" field might break the iteration.
for (grep {$h{$_}->STATE eq 'NY'} lazy(keys %h)){
$h{$_}->send_advertisement();
};
causes a lazy list to be passed to our filter function C<grep>, saving
us from allocating the entire C<keys> array. C<Grep> is still in
the default busy context, so it returns a busy array, which C<for>
can iterate over safely.
Tom Hughes wrote:
>
> In article <[EMAIL PROTECTED]>, "David L. Nicol"
><[EMAIL PROTECTED]> writes:
>
> > Hmmm. Not all external hash implementations support multiple
> > iterators, I don't know which ones do. If we had explicit
> > access to element->nextkey() that would make things more
> > complex for user.
>
> The first thing is that I don't expect iterators to be very user
> visible - certainly not to that kind of extent. As to external
> implementations that don't support multiple iterators, that might
> be a bit of a problem but I think it can be worked round.
>
> > I rely on keys(%h) to be free and clear of any issues %h
> > might have if it is assigned to during the iteration, and know
> > to watch for this when I'm writing code that will modify the
> > data while iterating it: I push the keys of all the new yorkers
> > to an array during the iteration, then I go through that list
> > and send them their letters and increment their letters-sent
> > fields.
>
> That is a bit of an issue I guess... I'll have to think about
> that a bit.
>
> > Its been so long that I don't see not having multiple iterators
> > as a problem.
>
> That isn't really the main thrust of what I'm thinking about
> as it was more something I was taking for granted would be dealt
> with as it has always been a "we must fix that some day" thing
> on p5p.
>
> > What would the syntax look like? I'll gladly look over your proposal
> > if you'd like me to, before you make it into an RFC
>
> I'm not planning an RFC at the moment as what I'm thinking about
> is more an implementation detail relating to a number of current
> language suggestions. I may do something in due course though.
>
> Tom
>
> --
> Tom Hughes ([EMAIL PROTECTED])
> http://www.compton.nu/
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
