Problem in nested sorts

[robic0]

I duplicate your finding ... if those two print statements are
commented out, both the nested sorts work correctly. So, it certainly
does seem that the sort operator cannot always be relied upon when used
with anonymous functions that contain anything but simple comparison.
That's really fine, as far as I'm concerned, now that I know ... I can
always declare a prototyped sort function in the future if I'm writing
code that I expect to get called from within a sort. I don't, however,
find any warnings about such code in the "sort" function documentation
in the Camel book, my primary reference.

There are any number of reasons why one might want to have what you
refer to as "extra" code in a sort. This comes up when sorting objects.
We have a large class library at our site, and one of the chief reasons
that we use Perl, and not some other language like Java, C, or Visual
Basic, is because it allows us to program at a high conceptual level,
throwing around lists of objects with sort, grep and map. If you are
sorting a list of objects, you might have code like this:

my @sortedList = sort { $a->method() <=> $b->method() } @list;

A list of instantiated objects from which your calling method() to compare
encapsulated data? Cool... Just remember {} is a block, not an anonymous
sub.

In 'C', you can write structures (records or classes)
with common methods that know and act on common data, to be returned
to a pool collector, as in a sort or a find.

You should consider that any sort that can be done in method()
is absolutely misplaced when done in a general collecting scheme,
as you describe.

Has nothing to do with Perl sort. This is just common knowledge.
There is no example in 'C' you can give me that would justify this at all.

Sorry dude, the find is good, the premise is wrong.

robic0