When I see a Swartzian Transform, I think, "Ah! he's sorting the data".

If I see:

    @a = sort {COMPLEX EXPRESSION <=> COMPLEX EXPRESSION} @b
[download]

    @a = map {$_->[0]} sort {$a->[1] <=> $b->[1]} map {[$_, COMPLEX EX
+PRESSION]} @b
[download]

ST's feature is speed. Not readability.

Which is why I format the ST thus:

@a = map {
    $_->[0]
} sort {
    $a->[1] <=> $b->[1]
    ||
    $a->[ 2 ] cmp $b->[ 2 ]
} map {
    [ $_, COMPLEX EXPRESSION ]
} @b;
[download]

It makes the map / sort / map structure immediately apparent and allows for arbitrary complexity within the blocks, including multiple lines and even local variable declarations to be used without getting into that whole obfu-style thing.

A similar layout lends itself to the GRT:

@a = map{
    substr $_, 16
} sort map {
    m[...(\d+)...( \d+.\d+)...([a-z]4)...] or die "Illformed data '$_'
+";
    pack 'A4dNA*', $3, $2, $1, $_
} @b;
[download]

I never format single line if or else blocks one line either for same reason that doing so obscures the structure of the code.

I also like the consistancy with map/grep/sort chains and normal assignment. That is: result = manipulation of inputs

P6 has the pipe operators which allow you to reverse the flow src ==> tmp => dst, but I don't forsee me using that. I guess I grew up with assemblers, and even cpm/pip where dst = src was the way of things.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Regarding the code examples, I probably would have ended up somewhere in between. The OP used C-style for loops which would be better written as (0..12) and could have used more meaningful variables than $i and $j (like $row and $column) and used constants in place of the magic numbers 6 and 12, but it's legible. Your maps are cool, but take much longer to read than a for loop.

For example, I would change this:

my @nums = map { [qw/01 02 03 04 05 06 07 08 09 10 11 12/], } 1 .. 12;
[download]

# build the grid
my @grid;
my @row = qw/01 02 03 04 05 06 07 08 09 10 11 12/;
for (1..$NUMBER_OF_ROWS) {
    push @grid, \@row;
}
[download]

Probably just an oversight in posting, but there is a problem with this:

# build the grid
my @grid;
my @row = qw/01 02 03 04 05 06 07 08 09 10 11 12/;
for (1..$NUMBER_OF_ROWS) {
    push @grid, \@row;
}
[download]

#! perlmy @grid;
use strict;
use Data::Dumper;

use constant NUMBER_OF_ROWS => 12;

my @grid;
my @row = qw/01 02 03 04 05 06 07 08 09 10 11 12/;
for (1..NUMBER_OF_ROWS) {
    push @grid, \@row;
}

print Dumper \@grid;
__END__
$VAR1 = [
          [ '01', '02','03', '04', '05', '06', '07', '08', '09', '10',
+ '11', '12' ],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0],
          $VAR1->[0]
        ];
[download]

I made the same mistake initially by coding

my @grid = ( [ '01' .. '12' ] ) x 12;
[download]

This is being addressed in p6 by a new operator (which I cannot remember if it is 'xx' or 'xxx', but the effect is to iterate it's left operand, not replicate it. (As far as I understand it).

It has become my "standard conversion" for where I want to type

my @grid = ( .... ) x $n;
[download]

but need new instances instead of replicated references to exchange the 'x' operator for map:

my @grid = map{ ... } 1 .. 12;
[download]

I appreciate your misgivings about the 1 .. 12, but that is (as it's position on the right-hand side tends to denote (to my brain) the lesser suboperation of the significant operation; namely that I am initialising the array grid with separate instances of some constant expression. (Oh. And there are 12 of them :).

Beyond the thinko, the problem I have with the for/push method is that the main objective--that of initialising the array @grid--gets lost in the noise of the construction.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

FWIW, coming in such a long time after the party:

It has become my “standard conversion” for where I want to type

Of course, in this particular case, the correct, optimal solution is trivial:

my @grid = ( '01' .. '12' ) x 12;
[download]

In the more general case, I prefer another way, because it maintains symmetry:

my @grid = map @$_, ( [ '01' .. '12' ] ) x 12;
[download]

And to this:

Beyond the thinko, the problem I have with the for/push method is that the main objective – that of initialising the array @grid – gets lost in the noise of the construction.

I say bingo. That’s the reason I use Perl to begin with, rather than C. (“If I had a nickel for every time I wrote for( i = 0; i < LEN ; ++i ), …”)

Makeshifts last the longest.

Your maps are cool, but take much longer to read than a for loop.

<snip>

No doubt this looks horrible to you, but anyone can see what it does in a quick scan.

Is that really objectively true, or are you just more familiar with for and less use to map? Do you think there are any legitimate uses of map (and grep, fold, etc)?

I think map and grep often lead to code that is too dense to read quickly. I do use them, when I have an operation that is short and simple enough. In particular, grep is a good "Are there any like this in the list?" operation.