In the second bit of code there is a lot of contextual info to tell one to jump to

I've learned to stop worrying about this and enjoy writing LISP in Perl :)

Removing my tounge from my cheek, I think people shouldn't expect Perl to just be interpreted C. People who have a strong C background may have problems reading chained operations like that, but it's standard operating procedure in LISP and other functional languages. So when somebody tells you that the code you shown above is sloppy, you'll know which community they come from.

Now, I think you are correct to say that the index isn't a very pleasing way to end the statement. Maybe this will do it (untested):

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

Of course, now you have to explain to The Complainer the difference between lists and arrays.

I don't believe the OP's issue came from reading chained operations, but more from the switch between left-chaining and right-chaining in the revised code.

His one-liner:

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

was structured like:

 %h = ( op3 op2 op1 %h) op4;

where %h was acted upon by four operators in turn (keys, sort, map, and an array slice). But the order of operation was not linear. It flowed to the left, then sharply cut back to the right. In pseudo-scheme, that would have been:

(set! 'h 
  (hash-new
    (array-slice (1 2)
      (flatten-map (lambda (x) (list x (hash-get h x)))
        (sort stringcomp
          (hash-keys h))))))
[download]

and the dataflow would have been clear. A while ago on the Perl 6 language lists there was discussion of 'gozinta' operators which would have allowed you to adjust the order of things. I don't remember the exact syntax right now (and it may have been squashed, I forget), but his code could have been done something like so:

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

or...

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

Either way would have worked, and the dataflow is obvious without having to switch left/right more often.

If we wanted a statement that could be read from right to left completely we could use

%h = ( $_, $h{$_}) for ($_) = sort {$a <=> $b} keys %h;
[download]

"Take the keys of %h, sort them numericaly, take the first one and set the %h hash to the key and its value."

But I think this one is even more confusing. Maybe this

%h = ( $_, $h{$_}) for ($_,) = sort {$a <=> $b} keys %h;
[download]

would be better, the comma giving a hint that we do expect the sort to return several values, but we use just the first one.

Anyway in this case I would use some temp variable. Even though I did work with some functional languages and liked it :-)

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

Yes, Perl6 will let you say which direction you want the result to go. So, you can have your chains read left-to-right or right-to-left, at your discretion.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

I'd code that as

use List::Util qw[ min ];

%h = map{ 
    $_, $h{ $_ } 
} min keys %h;
[download]

Which I think clarifies things a lot as well as saving a little runtime.

I also favour breaking chains over several lines as I think it makes it easier to pick out what is going on.

If I needed to keep the lowest 2 or more elements then

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

Hmm, your solution for keeping the lowest 2 or more elements still puts the indexing at the end, but it changes the op structure to  %h = op4 (op2 op1 %h) op3 which from a jumping back and forth from beginning to end issue is worse. But it does change the structure in another way that suggests:

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

(that, by the way, is completely untested. Hmm, testing says it doesn't work, type of arg 1 of shift must be array, not sort. i wasn't aware that sort was a type. I wonder how to do what I want...)

I guess we read the code in different ways. I don't think of the code as a list of operations applied to %h, but as assigning the results of map to %h.

map takes a list and manipulates it. The fact that the input to map is also derived from %h is effectively moot. It could equally well be a completely different hash.

I look at

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

as: Take the first 3 from a list of sorted keys and feed them to map. Map those keys to key/value pairs and assign them to %h.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

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

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];
};
[download]

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]
};
[download]

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

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] ;
[download]

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'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.

It is clear why you focus on the writing, but I was trying to focus on the reading of code.

I see it much like the difference between

See spot.
Spot is a dog.
See the dish.
See the food.
The food is in the dish.
Spot runs to the dish.
Spot eats the food.
[download]

and

The dog, Spot, runs to the dish and eats the food.
[download]

What is gained?

Time. I can read the single line faster; if I have the ability to read it there is no loss of clarity. There is an increase in clarity through expressiveness: Dick and Jane may be readable in three word sentences but I would not want to read White Fang that way. Concise expressions allow larger thoughts to cohere by remaining nearby.

Be well.

If I was reading White Fang for the pleasure of it I agree.

but I'm reading White Fang to figure out why there is a slight logicial inconsistency dealing with a Lantern somehere in pages 36-98 or page 14 or pages 19-22, which in turn creates a slight problem in the plot timeline on page 132, I'll take the Dick and Jane Version.

ditto for your code.

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

Update: is this better or worse?

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

I find your version about the same. BlaisePascal's snippet and yours move me more toward:

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

But I don't see this as that important. My post was not about re-writing a bit of code so I could find it an easier read. My post was about improving code reading skills so all code is easier to read.

How much complexity one can absorb on one line seems to me to be a good thing to increase. Contrarily, perhaps I should try to derive more info from the indentation of code.

Be well.

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

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

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 the Perl Golf site. I think that recognizing why good code is good and why bad code is bad is helpful to your literacy.