what is the expression mean?
Jking
I am reading the perl code of Blosxom,
I can not quite catch the meaning of this expressiong:
%month2num = (nil=>'00', Jan=>'01', Feb=>'02', Mar=>'03', Apr=>'04',
May=>'05', Jun=>'06', Jul=>'07', Aug=>'08', Sep=>'09', Oct=>'10', Nov=>'11',
Dec=>'12');
@num2month = sort { $month2num{$a} <=> $month2num{$b} } keys %month2num;
how does the sort function works with keys?
Anyone can kindly explain it for me Pls?
Justin
Nathan
> %month2num = (nil=>'00', Jan=>'01', Feb=>'02', Mar=>'03', Apr=>'04',
> May=>'05', Jun=>'06', Jul=>'07', Aug=>'08', Sep=>'09', Oct=>'10', Nov=>'11',
> Dec=>'12');
This expression is defining a hash variable called %month2num; it
expresses the relation between a month and its number. The months are
called the "keys" and the numbers are called "values". For example,
$month2num{"Jan"} would give you the string '01'. The "=>" symbol is
used as a shorthand for this statement:
%month2num = ("nil",'00', "Jan",'01', "Feb",'02',"Mar",'03'....
>
> @num2month = sort { $month2num{$a} <=> $month2num{$b} } keys %month2num;
>
>
> how does the sort function works with keys?
The aptly named function "keys" returns a list of the keys of the hash.
In this case it would be the list of strings ("nil","Jan","Feb",....).
The function "sort" sorts a list and takes in an optional comparison
function to do the sort. After all, sorting tne month names
alphabetically is probably not what you want, right? So the statement is
saying in effect, "Retrieve the list of month names and sort them
according to number". The sorting function is being defined anonymously
with the <=> operator. You can learn about perl functions by typing
'man perl' at the command line if you use unix. You can also find
individual functions by using the perldoc program:
$ perldoc -f <funcname>
Hope this answer your question!
-Nathan
Jking
"Nathan" <us...@serverrb.net>
??????:2mRik.19160$N87....@nlpi068.nbdc.sbc.com...
Eric Pozharski
>> %month2num = (nil=>'00', Jan=>'01', Feb=>'02', Mar=>'03', Apr=>'04',
>> May=>'05', Jun=>'06', Jul=>'07', Aug=>'08', Sep=>'09', Oct=>'10',
>> Nov=>'11', Dec=>'12');
*SKIP*
> $month2num{"Jan"} would give you the string '01'. The "=>" symbol is
> used as a shorthand for this statement:
> %month2num = ("nil",'00', "Jan",'01', "Feb",'02',"Mar",'03'....
Not exactly. '=>' as a bonus B<quotes> whatever sequence of word
characters on the left side, so it won't be treated as expression:
21:35:50 40 [0:0]$ perl -wle '
> sub foo { q(bar) };
> %h = (foo, 1);
> print keys %h;'
bar
21:36:59 41 [0:0]$ perl -wle '
> sub foo { q(bar) };
> %h = (foo => 1);
> print keys %h;'
foo
>> @num2month = sort { $month2num{$a} <=> $month2num{$b} } keys
>> %month2num;
>>
>> how does the sort function works with keys?
B<sort> doesn't works with keys. It works with with a list applying at
pairs... Who said at every pair?
21:42:27 44 [0:0]$ perl -wle '
> @l = qw(0 1 2);
> @l = sort {
> warn $a, q(<=>), $b;
> $a <=> $b; }
> @l'
0<=>1 at -e line 3.
0<=>2 at -e line 3.
2<=>1 at -e line 3.
OK, let's back in business, B<sort> passes pairs to something (
C<perldoc -f sort> has more); in your case, that something is block.
Pairs are passed in I<$a> and I<$b> (C<perldoc -f sort> has more).
Those I<$a> and I<$b> variables are B<saint>, never mind to touch them
outside of B<sort> context.
> The aptly named function "keys" returns a list of the keys of the
> hash. In this case it would be the list of strings
> ("nil","Jan","Feb",....). The function "sort" sorts a list and takes
*SKIP*
No, no, no! Look at that shit! There's no order at all!!!
21:55:16 46 [0:0]$ perl -wle '
> %x = qw(0 1 2 3 4 5 6 7 8 9 10 11);
> print join q( - ), keys %x'
8 - 6 - 4 - 0 - 10 - 2
B<keys> intentionally mangles its output (C<perldoc -f keys> has more).
(Hmm,.. documentation says that order would be different between
different runs of the same code since 5.8.1. As of 5.8.8 it's not.
Debian specific quirks? Again?)
> Hope this answer your question!
Happy homework
--
Torvalds' goal for Linux is very simple: World Domination
Peter J. Holzer
> B<keys> intentionally mangles its output (C<perldoc -f keys> has more).
> (Hmm,.. documentation says that order would be different between
> different runs of the same code since 5.8.1. As of 5.8.8 it's not.
> Debian specific quirks? Again?)
No, not debian specific. The algorithm was changed again some time after
5.8.1. Now order changes only if the distribution is detected to be
particularly poor. Apparently the documentation wasn't updated.
hp (who asked the same question not too long ago)
Eric Pozharski
Documentation drift isn't good. It's very very bad (no smile).
> hp (who asked the same question not too long ago)
Is it a FAQ already?
Nathan
> Nathan <us...@serverrb.net> wrote:
>
>> The aptly named function "keys" returns a list of the keys of the
>> hash. In this case it would be the list of strings
>> ("nil","Jan","Feb",....). The function "sort" sorts a list and takes
> *SKIP*
>
> No, no, no! Look at that shit! There's no order at all!!!
>
> 21:55:16 46 [0:0]$ perl -wle '
>> %x = qw(0 1 2 3 4 5 6 7 8 9 10 11);
>> print join q( - ), keys %x'
> 8 - 6 - 4 - 0 - 10 - 2
Well I didn't mean to imply that that list came out in that specific
order, which I hope was implied by the ensuing discussion of using the
sort function. Also, what newsreader are you using? The B<> and C<> tags
really look confusing!
-Nathan
Peter J. Holzer
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> On 2008-07-28 19:06, Eric Pozharski <why...@pozharski.name> wrote:
>>> B<keys> intentionally mangles its output (C<perldoc -f keys> has
>>> more). (Hmm,.. documentation says that order would be different
>>> between different runs of the same code since 5.8.1. As of 5.8.8
>>> it's not. Debian specific quirks? Again?)
>> No, not debian specific. The algorithm was changed again some time
>> after 5.8.1.
After some poking around: Definitely before 5.8.4, probably in 5.8.2
(perl582delta mentions that the implementation has changed to become
binary compatible with 5.8.0 again, but doesn't mention that this also
turns off the preseeding in most cases. perl583delta mentions that the
hash code has been refactored but claims that no functional change
occured).
>> Now order changes only if the distribution is detected to
>> be particularly poor. Apparently the documentation wasn't updated.
>
> Documentation drift isn't good. It's very very bad (no smile).
for perldoc -f keys, the change is simple: Just change "is different" to
"may be different". For the longer discussion in perlsec, one would have
to look at the code to see how much of it still applies.
>> hp (who asked the same question not too long ago)
>
> Is it a FAQ already?
>
Does two times count as "frequently"?
hp
Eric Pozharski
> On 2008-07-29 19:46, Eric Pozharski <why...@pozharski.name> wrote:
>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>> On 2008-07-28 19:06, Eric Pozharski <why...@pozharski.name> wrote:
> for perldoc -f keys, the change is simple: Just change "is different"
> to "may be different". For the longer discussion in perlsec, one would
> have to look at the code to see how much of it still applies.
That's not the first time I struck at implementation and documentation
difference (at least, I'm not hitten, this time). I hope, that
documentation follows development (sometime it's other way).
>>> hp (who asked the same question not too long ago)
>> Is it a FAQ already?
> Does two times count as "frequently"?
Anyway. No one cares.
Eric Pozharski
*SKIP*
> sort function. Also, what newsreader are you using?
No comments.
> The B<> and C<> tags really look confusing!
No comments.
Michael Carman
> The B<> and C<> tags really look confusing!
perldoc perlpod
-mjc
Jürgen Exner
That may explain what they are but it doesn't stop making them look
confusing. I agree with Nathan and would prefer standard Usenet
conventions, like e.g. using underscore characters to add emphasis or
putting actual code in a line of its own if there is a risk of confusing
code and text.
jue