To the question in your previous post I would say that should work. Nice line by the way. UPDATE: Seems it won't work after all, see johngg's experiment

But the delete bevor add idea won't work, because hashed items get stored into specific slots depending on their hash value. I.e. new passengers always want to go to a seat that depends on their social security number, not to the seat that was vacated last.

What happens when a passengers wants a seat that is occupied, There are two mayor strategies to handle this (that I remember), one is to let more than one passenger sit on a seat, the other is to calculate another seat in a deterministic pattern until the passenger finds a free one (for example the next seat, or the 13th seat from this one). I believe perl hashes use the first method (more than one on a seat) but I'm not sure.

To the question in your previous post I would say that should work.

So would I and the line does look rather nice. Unfortunately, it doesn't seem to work as you might expect. It does look as if it is resetting the iterator but it is failing to consistently retrieve the values from the hash, only managing to get the value for key "six" twice and not getting any others.

knoppix@Microknoppix:~$ perl -Mstrict -wE '
> my %hash = (
>    one => q{ein},
>    two => q{zwei},
>    six => q{sechs},
>    );
> say qq{@{ [ %hash ] }};
> for ( 1 .. 9 )
> {
>     my ( $k, $v ) = each %hash || each %hash;
>     say qq{$_: $k => $v}
> }'
six sechs one ein two zwei
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
1: six => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
2: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
3: two => 
4: six => sechs
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
5: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
6: two => 
7: six => sechs
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
8: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
9: two => 
knoppix@Microknoppix:~$
[download]

I can't puzzle out what is going on here. I wondered if it was a precedence problem but changing each %hash to each( %hash ) made no difference.

Can anyone shed any light on what's happening here?

Update: A different approach to prove to myself that the each would behave as described.

knoppix@Microknoppix:~$ perl -Mstrict -wE '
> my %hash = (
>    one => q{ein},
>    two => q{zwei},
>    six => q{sechs},
>    );
> say qq{@{ [ %hash ] }};
> my $ct;
> for ( 1 .. 3 )
> {
>     while ( my ( $k, $v ) = each %hash )
>     {
>         $ct ++;
>         say qq{$ct: $k => $v}
>     }
> }'
six sechs one ein two zwei
1: six => sechs
2: one => ein
3: two => zwei
4: six => sechs
5: one => ein
6: two => zwei
7: six => sechs
8: one => ein
9: two => zwei
knoppix@Microknoppix:~$
[download]

Cheers,

JohnGG

It did take a while, but I finally got it. The || creates boolean, i.e. scalar context. And each() in scalar context returns only the key and not the index.

I was interested so I performed a bit of an experiment. If I understand correctly, this is similar to the setup you are aiming for:

#!/usr/bin/perl
use strict; use warnings; use 5.010;

my @az = 'a'..'z';
my %cache = ( a => 1, b => 1, c => 1 );

for (1..20) {
  my $key = each %cache || ( say "back to front!" and each %cache );
  say $key;
  delete $cache{$key};
  $key = $az[rand @az] . $key;
  $cache{$key} = 1;
}
[download]

Sample Result:

c
a
b
sa
qsa
zc
back to front!
zqsa
zzc
wb
izzc
ezqsa
cizzc
nwb
nnwb
eezqsa
back to front!
icizzc
bnnwb
neezqsa
back to front!
sneezqsa
jicizzc
[download]

So, you don't get perfect "oldest first" behavior. In particular, it is fully possible that you evict the most recently cached item. In the bus analogy, if any new cache items sit in a seat behind where the conductor is, they may be evicted prematurely. However, some amount of "oldest first" does seem to exist and from what you've said, this is probably "good enough" for your needs.

I do wonder whether adding items might eventually/occasionally cause perl to recompute the hash which might reset the conductor or cause an "old" key to be moved to a seat in front of the conductor's location so that the old key gets missed in a pass.