I am pleased with the first five responses in this thread. I was trying to start an broad discussion.

I'll re-emphasize my first point: I was not expecting this small practice to improve my Perling so much, so quickly. I wanted to advertise this to others. I thank Merlyn again for his post.

In the second part of my post I was trying to expose my cognitive state in dealing with the syntax of Perl. I hoped to elicit from my Perl betters some explanation of their mental process in parsing or reading code.

I feel that I mentally gloss over opening parentheses, braces and such, and that the bad habit comes from reading simple code. I wondered if the more fluent readers of Perl just do what I do, but better, or if there is some redirect or quirk at a parenthesis whose partner is not in sight.

Be well.

Personally, I think you're trying to do too much at once. The line doesn't have an easy flow to it. I'd break it up into two parts.

my @temp = map { $_ => $h{$_} } sort { $a <=> $b } keys %h;
%h = @temp[0,1];

This tells me I'm doing something with %h, then I'm reassigning that result back to %h; Of course, I could use a do statement, as so:

%h = do {
    my @temp = map { $_ => $h{$_} } sort { $a <=> $b } keys %h;
    @temp[0,1];
};

That's nicer, but I don't like having my chained operators so far from the left margin. While I limit myself to 80 columns, I like to keep it, if at all possible, in under 40.

%h = do {
    my @temp =
        map {
            $_ => $h{$_}
        } sort {
            $a <=> $b
        } keys %h;
    @temp[0,1]
};

That's how I write my LisPerl, with the chains listed vertically instead of horizontally.

What is the advantage to using the denser version? It seems that you lose clarity; what is gained thereby?

Whenever i notice map, i generally read the LIST part first followed by reading (BLOCK|EXPR) body, followed by anything before the map.

If any part of the map structure has more than 1 thing going on, i split it over multiple lines. Your example would be shaped like (excessive in this particular case)...

%h = ( map { $_ , $h{$_}; }
        sort { $a <=> $b }
          keys %h
     )[0,1] ;

I am not bothered by the array slice at the end. But as somebody else has/have noted, there is no need to squeeze every little bit of temporary variables at the cost of clarity.

As to reading code w/ parentheses ... my expectation is not to find nested parentheses; otherwise i have to work very hard to keep track of them. In the second case, i tend to indent and split the text on each opening parenthesis before doing anything else.

I offer another right-to-leftification of your example:

%h = map { $_->[0], $h{$_->[0]} } [ sort { $a<=>$b } keys %h ];

Do you find it more readable? Personally, I found the line breaks and indentation that other posters provided was more helpful in adding readability than making the direction consistent. But if you're going to do it on one line, it is helpful to have things go one direction.

Update: is this better or worse?

%h = map { $_, $h{$_} } map { $_->[0] } [ sort { $a<=>$b } keys %h ];

Take the keys, sort them, take the first one, and make the hash from the hash entry.

Having dinked around with the example for a bit, I think that the chief reason it is awkward to read is that it's kludgy. You're getting the minimum key value by sorting and indexing, instead of by using a min function.

use List::Util;
my $min_key = min(keys %h);
%h = ($min_key, $h{$min_key});

That's perfectly clear, efficient, and doesn't involve a lot of slinging data around. If you particularly hate the temp variable, you could obviate it with map (although I find that rather dogmatic):

%h = map { $_, $h{$_} } min(keys %h);

In the same way that variables should have purposeful names, chunks of code should look like what you're trying to accomplish. If there were no min() function already written, you could (and should) easily write your own, rather than inlining everything.

Update: if the issue is improving your ability to read code, well, bad code is always going to be hard to read. You could certainly practice at [http://terje2.perlgolf.org|the Perl Golf site]. I think that recognizing why good code is good and why bad code is bad is helpful to your literacy.