The writer is using short-circuiting to exit the block with -1 or 1 values; so that listtype sorts before listcode before funclist before every thing else.

I don't write that way. This seems to rely on luck as the block may yield "" which sort is not advertised to accept. I think it needs a catch-all  or ( $a cmp $b ).

Be well.

This seems to rely on luck as the block may yield "" which sort is not advertised to accept.

That code always returns 1 or -1 AFAICT. Can you explain?

Update: it will return false if $a or $b isn't any of the types tested for, but false isn't "", it's both 0 and "":

$ perl -we'@_ = sort { "" } 1,2'
Sort subroutine didn't return a numeric value at -e line 1.

$ perl -we'@_ = sort { !1 } 1,2'
[download]

Thanks for the correction. It was my error to be seduced by the control flow like use of logical short circuiting to the point of thinking statements instead of an expression. More succinctly: I had another braindead moment.

Now that you've drawn my attention to the code again. I say it is that baroque. My initial justification was just for the  and 1 stuff which I still don't find so bad.

I would still like a or $a cmp $b or a or 0 or  die "domain err". It is not readily apparent what is to happen with other/other comparisions. This seems like a significant decision point in the code (by the identifiers) and so a good place for extra clarity. I can imagine myself referring to this snippet to understand how all the subsequent parsing code is recieving data. This may be such a recurring problem in the codebase that it seems unimportant.

What does irk is the inconsistent use of short-circuiting, the sub-clauses are unnecessary and so confusing. (I just trusted that aspect the first time around.

If I were going to write in that form I'd write something like:

@List = sort {
    $a eq "one" and -1
 or $b eq "one" and 1
 or $a eq "two" and -1
 or $b eq "two" and 1   # no need to check if $a eq one
 or $a eq "thr" and -1
 or $b eq "thr" and 1
 or 0                   # advertising the default case
}
[download]

Be well.

Although you give examples of strange code and it does not pretend to be good, I can't resist pointing that:

code block given to sort must behave (as POD stays.)
Namely, once f(a,b) return false f(b,a) must return true.
Some versions of perl dumped core when fed some misbehaving comparision sub.
Such core dumps were fixed, but general rule remain: comparision sub must behave

This means that sort {rand(5) <=> rand(5)} is obviously wrong, but sort {1} also not good.

Best regards,
Courage, the Cowardly Dog