Probably overkill for what you want, but it handles a mix of nested hashes and arrays, and a few other refs as well.

sub traverse(&$) {
    my( $code, $ref ) = @_;
    my $d;
    $d = {
        SCALAR => sub{
            my $code = shift; my $ref = shift;
            return $code->( @_, $$ref );
        },
        ARRAY  => sub {
            my $code = shift; my $ref = shift;
            map $d->{ ref $ref->[ $_ ] }->( $code, $ref->[ $_ ], @_, $
+_ ), 
                0 .. $#$ref;
        },
        HASH  => sub {
            my $code = shift; my $ref  = shift;
            map $d->{ ref $ref->{ $_ } }->( $code, $ref->{ $_ }, @_, $
+_ ), 
                keys %$ref;
        },
        REF  => sub{
            my $code = shift; my $ref = shift;
            return $d->{ ref $$ref }->( $code, $$ref, @_ );
        },
        CODE => sub{
            my $code = shift; my $ref = shift;
            return $d->{ '' }->( $code, "$ref", @_ );
        },
        ''  => sub{
            my $code = shift; my $ref = shift;
            return $code->( @_, $ref );
        },
    };
    return $d->{ ref $ref }->( $code, $ref );
}

traverse { print join ',', @_ } \%hash;
[download]

You can also use it like this to build an array:

my @strings = traverse{ join',', @_ } \%HorAofHorA;
[download]

sub traverse {
    my ($b, $h) = @_;
    return ref $h
         ? map traverse([ @$b, $_ ], $h->{$_}), keys %$h
         : ( join ',', (@$b, $h) ) . "\n";
}

print traverse([], \%hash);
[download]

I'd make the second argument optional, so that the initial call to your subroutine is as simple as it could be.

I would probably do something like:

output(\%hash);

sub output {
    my ($hash, @keys) = @_;

    die 'Not a hashref' unless(ref($hash) eq 'HASH');

    foreach my $key (sort keys %$hash) {
        if(ref($hash->{$key}) eq 'HASH') {
            output($hash->{$key}, @keys, $key);
        } else {
            print join(', ', @keys, $key, $hash->{$key}), "\n";
        }
    }
}
[download]

update: added die.

use strict;
use Scalar::Util qw/reftype/;

my %hash_to_do

sub do_hash {
  my $hash_ref = shift;

  foreach my $key (keys %$hash_ref) {
    my $value_type = reftype $hash_ref->{$key};

    if ($value_type eq 'HASH') {
      do_hash($hash_ref->{$key});
    }
    else {
      # do something else
    }
  }
}
[download]

sub flatten
{
    my ($value) = @_;

    my $rtype = ref $value or return "=$value\n"; # ends recursion

    if ( $rtype eq 'ARRAY' ) {
        return map {
            my $i = $_; map { "[$i]$_" } flatten( $value->[ $_ ] );
        } ( 0 .. $#$value );
    }
    elsif ( $rtype eq 'HASH' ) {
        return map {
            my $k = $_; map { "{$k}$_" } flatten( $value->{ $_ } );
        } sort keys %$value;
    }
    
    die 'flatten only handles scalars, arefs, or hrefs';
}

print for flatten( \%hohoh );
[download]

apomatix,
I wonder how else you thought of doing it.

As I indicated, I considered an iterator. Here is a very unpolished working version:

Read more... (1423 Bytes)

As you can see, it is far more complex than the recursive solution. Also, the iterator could result in bizarre behavior if the hash isn't walked all at once. This is because each itself is an iterator that is reset any time there is a call to keys or values. In the recursive version, the hash is traversed all at once so there isn't an opportunity to reset the iterator mid-traversal.

Here is the stack based iterative version I was thinking of. I think it is the nicest because it is how my brain works:

Read more... (730 Bytes)

However, I don't think your solution would be easy for someone "just learning Perl".

Why? That's an honest question. Provided you understand references (which he does), it should be straight forward. That is unless you are like me and have a hard time thinking recursively but the whole point of writing it recursively was that most programmers I know think that way naturally. What about it do you think a seasoned C++ programmer would find hard to understand?

Cheers - L~R

Recursion is a very powerful technique, and fairly cheap to do.   Lately, I have also found useful the notion of a “work-to-do stack,” in which we push the first item(s) onto the stack initially, and then repeat a process in a simple loop until the stack becomes empty.   As more work is discovered, it is pushed onto the stack (or stacks, as the case may be).

This is, of course, very similar to recursion in the simple case, but it can come in handy when “the case” becomes “not quite so simple,” e.g. when there might need to be a choice concerning “what to do next.”   (Priorities, prerequisites, and so forth ...)   A recursion is always FIFO (“first-in first-out”), but this does not have to be.   All the work will eventually get done, no matter how much work there is, but it is not strictly obliged to be FIFO.

Perhaps I am misunderstanding your comment, but if your recursion uses a stack (which, I would say, at least the calls do), the solution has to be LIFO. A queue would be FIFO.

This could just be a difference between understanding your comment differently than the way you meant to say it.

--MidLifeXis

Stack.   Queue.   Whatever.   :-D

“Verily, verily, I code unto thee:   he who seeks to be first, shall be last...”   :-;

You store the items, in some method and according to some suitable discipline, and then you “work through the list(s).”   That’s the gist of it.