rrr@u02.svl.cdc.com (Rich Ragan) (12/21/90)
I keep needing to get at the current index of the iterator.
For example, the following piece of code from a mail gateway
moves the user who was being processed during a crash to the
front of the process list on the next run by swapping
with the current first user. The folks array has their name
and the signons array has the info to sign on the user with
the mail system.
# Move interrupted user to the first entry in the list.
for ($i=0; $i <= $#folks;$i++) {
if ($folks[$i] eq $interrupted_user) {
($signons[0], $signons[$i]) = ($signons[$i], $signons[0]);
($folks[0], $folks[$i]) = ($folks[$i], $folks[0]);
last;
}
}
Generally, I hate to code for loops with explicit loop counters because
its easy to be off by one on the termination test [You can't mess up
foreach (@folks) ]. For the sake of discussion, I will invent some
syntax which is likely not to be just what one would want to use but
all the $special-chars have pretty much been gobbled up. In the revised
example @. has the value of the current index of the iterator array.
# Move interrupted user to the first entry in the list.
for (@folks) {
if ($_ eq $interrupted_user) {
($signons[0], $signons[@.]) = ($signons[@.], $signons[0]);
($folks[0], $folks[@.]) = ($folks[@.], $folks[0]);
last;
}
}
Access to the current iterator index would seem to be useful for other
common things such as "the previous element" or "the next element" that
I have seen asked about in this group.
My example above would be further simplified by enhanced support for
arrays. In particular, a grep-like array search but one that returned
the index rather than the value of the first match. Thus it becomes,
if (($loc = locate(@folks, $interrupted_user))+1) {
($signons[0], $signons[$loc]) = ($signons[$loc], $signons[0]);
($folks[0], $folks[$loc]) = ($folks[$loc], $folks[0]);
}
An extension of this would return an array of element locations that
matched the string. This could be used to access the interesting
elements. This could be further extended by allowing the match
string to be a regexp.
Any thoughts on these ideas. I suspect that strengthening the array
features of perl will improve its power and speed (fewer things to
interpret per unit of work done)
--
*
/ \
/ o \ Seasons Greetings,
/o o\ Richard R. Ragan rrr@svl.cdc.com (408) 496-4340
-------- Control Data Corporation--Silicon Valley Operations
||henkp@ruuinf.cs.ruu.nl (Henk P. Penning) (12/21/90)
In article <29428@shamash.cdc.com> rrr@u02.svl.cdc.com (Rich Ragan) writes: >I keep needing to get at the current index of the iterator. >Access to the current iterator index would seem to be useful for other >common things such as "the previous element" or "the next element" that >I have seen asked about in this group. > [ examples and proposal for getting the index of the current iterator ] >Any thoughts on these ideas. I suspect that strengthening the array >features of perl will improve its power and speed (fewer things to >interpret per unit of work done) I agree; one of Perl's strongest points could be made stronger. I think it would be very usefull if some for-construct could take a list of iterators and arrays in stead of just one. Something like: forall $elem1, $elem2, $elem3 ( @row1 ; @row2 ; @row3 ) { zip info in row1, row2, row3 } Then you could say: forall $elem, $i ( @row ; 0..$#row ) { ... } Or: forall $a, $b ( @a ; @b ) { $a += $b ; } === HenkP === -- Henk P. Penning, Dept of Computer Science, Utrecht University. Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-534106 e-mail : henkp@cs.ruu.nl (uucp to hp4nl!ruuinf!henkp)