Excuse me, but what you are calling syntactic sugar, I call grammar!. Actually I find your comment diminishing towards all those fantastic computer linguistics that have been working so hard to incorporate iterative behaviors into the natural language of Perl. Choosing long used idioms over major parts of the grammar is your choice but personally I feel you are staying one step behind. Take Perl 6 for example where they are taking these concepts even a 1000 steps further!
Just doing a bit of googling, finding tons of examples. This one from the perl6 archives is already from 2000:
The ability to take an indexed slice of a hash is desired. This would allow the programmer to pare out several keys and values from hash A into a new hash B, for greatest flexibility. Currently, this is only available through map():
%other = map { $_ => $sounds->{$_} } qw(lizard duck);
Which could be simplified to:
%other = slice(%$sounds, { qw(lizard duck) }); # or,
%other = (%$sounds =~ sl/lizard duck/h); # or,
%other = %$sounds->{'lizard', 'duck'}; # or,
%other = %{$sounds}{ qw(lizard duck) }; # trad'l
Syntactic sugar? Sure, whatever.
edit: corrected typo, changed last comment. | [reply] [d/l] [select] |
Actually I find your comment diminishing towards all those fantastic computer linguistics that have been working so hard to incorporate iterative behaviors into the natural language of Perl.
Excuse me, syntactic sugar is in no way diminishing nor pejorative. It is sweet! I love it! It enables me to write things this or that way as I see fit for the task, conciseness, readability and so on, and it is one of the major strengths of perl.
I have demonstrated that the OPs foreach loop can be rewritten in terms of map and grep, and the internal code path is the same - the very definition of syntactic sugar. Nothing bad about that.
But my major point is: having a working solution means "job done" in the first iteration; improvement can be done into various directions (performance, readability, maintainability, conciseness, exploring grammar, to mention a few) and each has its place and merits.
Hash slicing is sweet - I use it all the time. But in the case of the OP, there's evaluating the sliced hash values at the moment the slice is done involved, so the examples you presented don't fit.
Furthermore, when programming, I am dumb or pretend to be so, because, as the saying goes
Debugging a program is more difficult than writing it in the first place. Therefore, if you write your program as smart as you are, you are, by definition, too dumb to debug it.
I have been clubbed to death by my cow-orkers for using the Highlander List Asserter for populating hashes
my %hash = (
foo => 'bar',
(baz => $quux) x!! $quux, # list repitition, see "x" in perlop
);
and they accused me of writing unreadable code and shunned me as a developer. They insisted in that particular piece to be written as
my %hash = (
foo => 'bar',
);
if ($quux) {
$hash{baz} = $quux;
}
because nobody groks what x!! means. Silly, in my eyes, because once you see that construct, as strange as it may look, and reading the comment and reading perlop, you know what it does and won't forget it. Ah well...
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] [d/l] [select] |
Hello shmem,
Sorry for taking your comment negatively. I should have taken it possitively
Regards to Highlander List Asserter, I am not going to defend you against what your colleagues said. Creating a coding standard should be a team effort after all.
The only problem that I have with x!! is that two operators have been pulled together making it look like one operator. Look at the infamous C --> operator for example
By the way, the Highlander List Asserter as you call it, I also found it mentioned here, but it is being called The List Squash Operator x (which leads to here: here)
edit: added extra link to perlmonks node.
edit: added words: 'you against'. I meant the opposite...
| [reply] [d/l] |
| [reply] [d/l] [select] |