Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

array iterator does not track a growing array #2771

Closed
p6rt opened this issue May 21, 2012 · 7 comments
Closed

array iterator does not track a growing array #2771

p6rt opened this issue May 21, 2012 · 7 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 21, 2012

Migrated from rt.perl.org#113026 (status was 'resolved')

Searchable as RT113026$

@p6rt
Copy link
Author

p6rt commented May 21, 2012

From @Siddhant

$ perl6 -v
This is perl6 version 2012.05-15-gdca0fa6 built on parrot 4.4.0
revision RELEASE_4_4_0

<sisar> so here is the same code in perl6 and python​:
https://gist.github.com/2762953. While the perl6 the loop terminates,
in pyhton it is an infinite loop. Though both behaviour have their
reasons, I can't decide which is better.
<sisar> why python's behaviour is logical, perl6's behaviour is trying
to prevent one from potentially infinite loops
...
<sisar> so, perl6 makes a temporary copy of @​array before it even
starts looping. Why ?
...
<flussence> it counts the array then iterates over it
...
<flussence> copying every array just to loop over it would be crazy
inefficient, I think only PHP does that (and only because it uses copy
on write)
<sisar> flussence​: what are merits of that, counting before iterating ?
<sisar> flussence​: aye, making a copy would be super inefficient.
<flussence> if you have an SQL result pretending to be an array, you
don't want it going off and calling a .count that does "select
count(*)" on every iteration
<sisar> flussence​: i'm sorry i'm not familiar with SQL
<geekosaur> don't worry about it. point is that an array might not be
an array, it might be a big chunk of code pretending to be an array
<geekosaur> and you don't want to hammer that big chunk of code pointlessly
<flussence> it'd be like calling strlen() in C on a really big string
...
<TimToady> the whole point of lazy lists is that you never ask for the
size of something you're iterating over if you can help it
<TimToady> and I think an array iterator should be able to track a
growing array without snapshotting the old length
<flussence> that makes sense, but I can't imagine it being fun to implement :)
...
<sisar> TimToady​: so it is a genuine bug? fwiw, both niecza and rakudo
iterate only twice.
<TimToady> I think so

@p6rt
Copy link
Author

p6rt commented May 21, 2012

From @Siddhant

(so please ignore my initial report, because it was lazily written,
here is the proper bugreport, restated with clarity)

The following loop should iterate infinitely, but it does not​:

  my @​array = 1, 2;

  for @​array -> $n {
  $n.say;
  @​array.push​: $n + 2;
  }

  say @​rray;

$ perl6 --version
This is perl6 version 2012.05-15-gdca0fa6 built on parrot 4.4.0
revision RELEASE_4_4_0

bug discovered​: http://irclog.perlgeek.de/perl6/2012-05-21#i_5619326

@p6rt
Copy link
Author

p6rt commented May 21, 2012

From @pmichaud

I suspect this bug may be related to #​112716
(https://rt-archive.perl.org/perl6/Ticket/Display.html?id=112716); the .map()
operation (which 'for' uses) tends to be a bit too eager in evaluating
its invocant list.

I've taken both bugs and will work on a fix shortly.

Pm

@p6rt
Copy link
Author

p6rt commented May 21, 2012

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented May 21, 2012

From @kyleha

I put a test for this in S04-statements/for.t

@p6rt
Copy link
Author

p6rt commented Aug 29, 2015

From @coke

On Mon May 21 11​:45​:12 2012, KyleHa wrote​:

I put a test for this in S04-statements/for.t

Which is now passing in the glr branch. Closing ticket.
--
Will "Coke" Coleda

@p6rt p6rt closed this as completed Aug 29, 2015
@p6rt
Copy link
Author

p6rt commented Aug 29, 2015

@coke - Status changed from 'open' to 'resolved'

@p6rt p6rt added the glr label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant