In message <[EMAIL PROTECTED]>
"David L. Nicol" <[EMAIL PROTECTED]> wrote:
[ lots of stuff about when it is safe to create implicit iterators
for the keys operator, based on a private message of mine ]
I should perhaps add a bit of context here... A message of mine to
the list yesterday referring to the inefficiency of looping over keys
for a large hash lead to a couple of people mailing me regarding my
thoughts on how iterators might fix the problem.
I expressed my thoughts to one of my correspondents as follows:
: So far the only iterator is that used by each, which is a single
: iterator for each hash so you have to be careful not to try and
: reuse it in the middle of an iteration. That has long been something
: that people have wanted to fix.
:
: Equally there has been talk about making things like these use an
: interator automatically:
:
: for (@x)
: {
: ...
: }
:
: for (keys %x)
: {
: ...
: }
:
: They are common idioms which can be very inefficient for large
: arrays and hashes as a list is built on the stack of all the
: values and that is then iterated over.
:
: I think the ideal - and this is really an internals issue and
: not a language issue - is that ops such as for would expect to
: be given an iterator as argument. Where the parser sees a simple
: array it would put a create-array-iterator op in the tree before
: the for op and where it sees a list of values it would cause a
: temporary array/list to be created, and iterator for which could
: be passed to the for op.
:
: Obviously this could be generalised to grep/map/reduce/zip or
: whatever - grep and map currently work more like this anyway.
:
: You could then make the optimiser as clever as you liked about
: trying to find a cheap way to iterate over the values. A case
: like this:
:
: for (@x, @y, @z)
: {
: ...
: }
:
: Could be made to create some sort of compound iterator that
: would move over each list in turn so you didn't have to flatten
: them all out.
:
: Just a few ideas anyway...
I also engaged in a correspondence with David which lead to him
pointing out the problem that someone might rely on keys fixing
the state of the hash and my replying with the message he quoted.
I still think we need to try and find a way to use iterators
implicitly to resolve these problems but obviously the issues
that David raises are serious ones that must be addressed by
any solution.
I realise that much of this is really about internals so I will
ask that any followups which relate to implementation rather than
syntax changes need to support this go to the internals list rather
than the language list.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...If life gives you lemons, make lemonade.
