|
Posted by nolo contendere on March 26, 2008, 10:27 am
Please log in for more thread options
> nolo contendere wrote:
> >> Ben Morrow wrote:
> >> [...]
>
> >>>> use strict;
> >>>> use warnings;
>
> >>>> my @a =3D qw/a b c/;
> >>>> for my $v (@a) {
> >>>> push @a,'d' if $v eq 'c';
> >>>> print "$v\n";
> >>>> }
>
> >>> Good point. for is a little weird in this respect...
>
> >> Nothing really weird about it. In that case above, it's no different
> >> than:
>
> >> for (my $i=3D0; $i<@a; $i++) {
> >> my $v =3D $a[$i];
> >> push @a,'d' if $v eq 'c';
> >> print "$v\n";
>
> >> }
>
> >> In either case, it's going over the array, one element at a time, in
> >> sequence, s oif you "push" something onto the end, it grows the
> >> array by one and thus the for look keeps going.
>
> > I think the 'weirdness' stems from the notion that 'for' supposedly
> > builds up a list prior to iterating over it,
>
> Exactly. It builds a list, when necessary (like when you
> use =A0 for (<FH>) { ... } =A0 ), unless it's alreayd there ( like
> with =A0 for my $element (@array) { ... } =A0 ) and /THEN/ iterates over i=
t.
>
> It just keeps going until the list is expended. Adding to the array like
> in the quoted examples above makes the list longer and hence the extra
> iteration (since the length of the list is checked each time through the
> loop.)
>
Provably untrue. See Ben's example. I'll restate the concept below.
my @ary =3D qw/a b c/;
# for (@ary, ()) {
# for ( (), @ary ) {
for ( @ary ) {
push @ary, 'd' if /c/;
print;
}
=2E..
only the uncommented 'for' line prints a 'd' at the end. so what you
say MAY be true if LIST is ONLY an array.
|
|
Posted by szr on March 27, 2008, 12:45 am
Please log in for more thread options
nolo contendere wrote:
>> nolo contendere wrote:
>>>> Ben Morrow wrote:
>>>> [...]
>>
>>>>>> use strict;
>>>>>> use warnings;
>>
>>>>>> my @a = qw/a b c/;
>>>>>> for my $v (@a) {
>>>>>> push @a,'d' if $v eq 'c';
>>>>>> print "$v\n";
>>>>>> }
>>
>>>>> Good point. for is a little weird in this respect...
>>
>>>> Nothing really weird about it. In that case above, it's no
>>>> different than:
>>
>>>> for (my $i=0; $i<@a; $i++) {
>>>> my $v = $a[$i];
>>>> push @a,'d' if $v eq 'c';
>>>> print "$v\n";
>>
>>>> }
>>
>>>> In either case, it's going over the array, one element at a time,
>>>> in sequence, s oif you "push" something onto the end, it grows the
>>>> array by one and thus the for look keeps going.
>>
>>> I think the 'weirdness' stems from the notion that 'for' supposedly
>>> builds up a list prior to iterating over it,
>>
>> Exactly. It builds a list, when necessary (like when you
>> use for (<FH>) { ... } ), unless it's alreayd there ( like
>> with for my $element (@array) { ... } ) and /THEN/ iterates over it.
>>
>> It just keeps going until the list is expended. Adding to the array
>> like in the quoted examples above makes the list longer and hence
>> the extra iteration (since the length of the list is checked each
>> time through the loop.)
>>
>
> Provably untrue. See Ben's example. I'll restate the concept below.
>
> my @ary = qw/a b c/;
> # for (@ary, ()) {
> # for ( (), @ary ) {
> for ( @ary ) {
> push @ary, 'd' if /c/;
> print;
> }
>
> ...
>
> only the uncommented 'for' line prints a 'd' at the end. so what you
> say MAY be true if LIST is ONLY an array.
Isn't that because the two commented one are two lists being combined
into a new list, and it's *that* new list that's being iterated over, so
even if you add to @ary, it doesn't change the "new list", which is just
that, a new list created at the start of the loop before iterating
begins - therefore the values of the new list are set and @ary has
nothing to do with it after the create of the "new list."
Isn't this correct?
--
szr
|
|
Posted by Peter J. Holzer on March 27, 2008, 4:26 pm
Please log in for more thread options > nolo contendere wrote:
>> Provably untrue. See Ben's example. I'll restate the concept below.
>>
>> my @ary = qw/a b c/;
>> # for (@ary, ()) {
>> # for ( (), @ary ) {
>> for ( @ary ) {
>> push @ary, 'd' if /c/;
>> print;
>> }
>>
>> ...
>>
>> only the uncommented 'for' line prints a 'd' at the end. so what you
>> say MAY be true if LIST is ONLY an array.
>
> Isn't that because the two commented one are two lists being combined
> into a new list, and it's *that* new list that's being iterated over, so
> even if you add to @ary, it doesn't change the "new list", which is just
> that, a new list created at the start of the loop before iterating
> begins - therefore the values of the new list are set and @ary has
> nothing to do with it after the create of the "new list."
Yes. But the same should be true for
for (@ary) {
...
}
for() expects a list, the list is constructed from the elements of @ary.
If you modify @ary after the list is constructed, the list shouldn't be
affected, but it is. I think Ben Morrow is right here: This smells like
an optimization: If there is only a single array, it can be used
directly instead of creating a list from it.
hp
|
|
Posted by szr on March 27, 2008, 11:26 pm
Please log in for more thread options Peter J. Holzer wrote:
>> nolo contendere wrote:
>>> Provably untrue. See Ben's example. I'll restate the concept below.
>>>
>>> my @ary = qw/a b c/;
>>> # for (@ary, ()) {
>>> # for ( (), @ary ) {
>>> for ( @ary ) {
>>> push @ary, 'd' if /c/;
>>> print;
>>> }
>>>
>>> ...
>>>
>>> only the uncommented 'for' line prints a 'd' at the end. so what you
>>> say MAY be true if LIST is ONLY an array.
>>
>> Isn't that because the two commented one are two lists being combined
>> into a new list, and it's *that* new list that's being iterated
>> over, so even if you add to @ary, it doesn't change the "new list",
>> which is just that, a new list created at the start of the loop
>> before iterating begins - therefore the values of the new list are
>> set and @ary has nothing to do with it after the create of the "new
>> list."
>
> Yes. But the same should be true for
>
> for (@ary) {
> ...
> }
>
> for() expects a list, the list is constructed from the elements of
> @ary. If you modify @ary after the list is constructed, the list
> shouldn't be affected, but it is. I think Ben Morrow is right here:
> This smells like an optimization: If there is only a single array, it
> can be used directly instead of creating a list from it.
Actually the behaviors of "for (@ary)" and "for (@ary, ())" do seem
consistant if you really think about it. The resulting list is what it
iterates over (from the first element, to what ever *count* is... in the
former case *count* come fro mthe array, and since the condition is
checked at the start of each iteration, if the array is added to, the
count is incremented.
In the latter case, a new list is created from contents of @ary + an
empty list, which gives you a new list, which contains the values of
@ary, but is a new seperate list, and thus is not effected by changes to
@ary because it has it's own copy of @ary's values.
--
szr
|
|
Posted by Ben Morrow on March 27, 2008, 11:57 pm
Please log in for more thread options
>
> Actually the behaviors of "for (@ary)" and "for (@ary, ())" do seem
> consistant if you really think about it. The resulting list is what it
> iterates over (from the first element, to what ever *count* is... in the
> former case *count* come fro mthe array, and since the condition is
> checked at the start of each iteration, if the array is added to, the
> count is incremented.
>
> In the latter case, a new list is created from contents of @ary + an
> empty list, which gives you a new list, which contains the values of
> @ary, but is a new seperate list, and thus is not effected by changes to
> @ary because it has it's own copy of @ary's values.
OK, now explain to me why
my @ary = qw/a b c/;
print map { /c/ and push @ary, 'd'; $_ } @ary;
*doesn't* work like that :).
Ben
|
| Similar Threads | Posted | | Asynchronous readline? | September 6, 2004, 9:27 am |
| Term::ReadLine::GNU problem | January 1, 2006, 11:57 am |
| ReadKey/ ReadLine query | July 4, 2006, 2:40 am |
| readline - possible security hole | March 30, 2007, 8:50 am |
| circular references, chdir() and Term::ReadLine::Gnu? | February 7, 2006, 8:09 pm |
| Strange characters using Term::Readline on Win32 | July 28, 2006, 9:05 am |
| HELP: readline() on unopened filehandle DATA at G:/PERLLIB/LIB/site_perl/5.8.2/MIME/WordDecoder.pm line 579. | May 21, 2006, 10:59 am |
| foreach vs. for | October 24, 2004, 6:18 pm |
| foreach in my | May 18, 2005, 10:40 am |
| Using foreach?? maybe.. | June 3, 2007, 12:30 pm |
|
XML Sitemap