sub find_paring()
{
    my $white_player = shift;
    my $black_player = "none";

    # Get a list of players still in the running
    my @possible_opponents =
        keys %{$matches_remaining{$white_player}};

    # Shuffle the list to add some randomness, then find the first
    # avaliable opponent.
    &shuffle(\@possible_opponents);
    foreach (@possible_opponents)
    {
        # Once we have a valid match, we remove the entries from the
        # match hash, and return the pair.
        if (exists $matches_remaining{$_}{$white_player}){
            $black_player = $_;
            delete $matches_remaining{$white_player}{$_};
            delete $matches_remaining{$_}{$white_player};
            last;
        }
    }

    # Return the info we have
    return ($white_player, $black_player);
}
[download]

Hmmmm....

sub find_paring()
{
  my $white_player = shift;
[download]

Looks like a conflict of interest there. Can't really shift if you aren't allowing anything to be passed. Try

sub find_paring
{
  my $white_player = shift;
[download]

I think you'll be happier.
my @a=qw(random brilliant braindead); print $a[rand(@a)];

Umm, I have to disagree with you here. The code


sub find_parsing()
{
  ...
}
[download]

is equivalent to


sub find_parsing
{
  ...
}
[download]

I always start my subroutines with sub function() (a habit from shell programming days). Strict argument prototyping is not necessary with Perl though.

Take a look at perldoc perlsyn (the section on Foreach) for more information but the short answer is yes.

and is there a way to get the behavior I'm looking for, short of using some kind of intermediate variable?

As Roger shows above just change your looping variable, and set $black_player to the value you before you exit the loop.

-enlil

sub find_paring() {
  my $wp = $_[0];
  foreach my $bp (&shuffle keys %{$matches_remaining{$wp}}) {
    if (exists $matches_remaining{$bp}{$wp})  {
      delete $matches_remaining{$wp}{$bp};
      delete $matches_remaining{$bp}{$wp};
      return ($wp, $bp);
    }
  }
  # Else return undef
  undef;
}
[download]

Actually, my() and our() do not behave the same from a subroutine. Both define a lexical context for the variable, however, my() allocates a new variable each time it is evaluated, while our() reuses a global.

For recursive subroutines, or subroutines that are accessed at the same time from multiple threads, my() variables are safe, while our() variables are unsafe.

This is being a little picky, but I noted you used:

sub find_pairing($white_player){ ... }
[download]

in the code snippet. This prototype will work, but isn't strictly correct. It would be better to say:

sub find_pairing($) { ... }
[download]

I also noted that some of the replies used:

sub find_pairing() {
    my $white_player = shift;
    ...
}
[download]

This is bad. If you call this method after this declaration, then a call like find_pairing("Bob") will fail because the prototype will accept no arguments. It would be better to say nothing about the signature of the subroutine like:

sub find_pairing { ... }
[download]

Anyway, you're all probably aware of this, but I wanted to make sure the casual browser, who might not, knows the difference between these slight variations. I look forward to Perl 6, where this cruft will be cleaned up.

Better yet, avoid the use of prototypes altogether in Perl. They are broken when it comes to actual programmer expectations. $ means "force scalar context" not "expect a scalar". Note that find_pairing(@list) does not generate a compile time error, but will generate perhaps-unexpected runtime behaviour.