[16841] in Perl-Users-Digest
Perl-Users Digest, Issue: 4253 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 7 21:10:28 2000
Date: Thu, 7 Sep 2000 18:10:16 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <968375416-v9-i4253@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 7 Sep 2000 Volume: 9 Number: 4253
Today's topics:
Re: Small golf problem <yanick@babyl.sympatico.ca>
Re: Small golf problem <rick.delaney@home.com>
Re: Small golf problem <yanick@babyl.sympatico.ca>
Re: Sorting again. (Logan Shaw)
Re: Stable sorting <jpl@research.att.com>
Re: The Heartbreak of Inscrutable Perl Code (Craig Berry)
Re: The Heartbreak of Inscrutable Perl Code (Malcolm Dew-Jones)
Re: The Heartbreak of Inscrutable Perl Code (Abigail)
Re: The Heartbreak of Inscrutable Perl Code (Avast)
Re: The Heartbreak of Inscrutable Perl Code (Abigail)
Re: The Heartbreak of Inscrutable Perl Code (Avast)
Re: The Heartbreak of Inscrutable Perl Code (Avast)
Re: The Heartbreak of Inscrutable Perl Code (Avast)
two questions- help interlocator@my-deja.com
Re: use strict: why? (Tim Hammerquist)
Re: use strict: why? (Tim Hammerquist)
Re: use strict: why? (Tim Hammerquist)
Re: Where is the Perl Newbie or Begginers group? (Chris Fedde)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 07 Sep 2000 22:48:23 GMT
From: Yanick Champoux <yanick@babyl.sympatico.ca>
Subject: Re: Small golf problem
Message-Id: <XWUt5.243945$1h3.4538681@news20.bellglobal.com>
Craig Berry <cberry@cinenet.net> wrote:
: Yanick Champoux (yanick@babyl.sympatico.ca) wrote:
: : That one is a wee bit shorter. But I can't vouch
: : for the 'smarter' part. :)
: :
: : my %foo = ( key1 => 1, key2 => 1, key3 => 0, key4 => 0 );
: :
: : my $s = ';';
: : $s = $foo{$_}?"$_,$s":"$s,$_" for keys %foo;
: : $s =~ s/,?;,?/;/;
: :
: : print $s;
: Nice. Or how about:
: @a=grep{$foo{$_}}keys%foo;
: delete@foo{@a};
: print join';',map{join',',@$_}[keys%foo],\@a;
Cool. But still, mine is a wee bit shorter. ;)
Although not as short as the one proposed by Rick Delaney. :(
# Rick Delaney (58chr)
@0,@1;push@{$foo{$_}},$_ for keys%foo;$"=",";print"@1;@0";
# Craig Berry (86chr)
@a=grep{$foo{$_}}keys%foo;delete@foo{@a};
print join';',map{join',',@$_}[keys%foo],\@a;
# Yanick Champoux, v1 (70chr)
$s=';';$s=$foo{$_}?"$_,$s":"$s,$_"for keys%foo;$s=~s/,?;,?/;/;print$s;
# Yanick Champoux, v2 (69chr)
$_=join',',sort map"$foo{$_}$_",keys%foo;s/,1/;/;s/(^|,)\d/$1/g;print;
Joy,
Yanick
--
$_="+21P-A6-d-.+i-51-12+V-#+22-;-L+6-2-H+6-21+R+3-5-13+T-12";
s/[#.A-Wild;]/ord$&/eg;while( /[-+]\d+/g ){ @a or @a=($&) and next;
unshift @a, map {($_+$&)/2 => ($_-$&)/2} pop @a; } print map chr, @a;
------------------------------
Date: Fri, 08 Sep 2000 00:07:11 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: Small golf problem
Message-Id: <39B8302F.9AF3225F@home.com>
Yanick Champoux wrote:
>
> # Rick Delaney (58chr)
> @0,@1;push@{$foo{$_}},$_ for keys%foo;$"=",";print"@1;@0";
When 5.6.1 comes out, this won't even need the first 6 characters. :-)
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Fri, 08 Sep 2000 00:29:06 GMT
From: Yanick Champoux <yanick@babyl.sympatico.ca>
Subject: Re: Small golf problem
Message-Id: <mpWt5.1188$WD3.40232@news20.bellglobal.com>
Rick Delaney <rick.delaney@home.com> wrote:
: Yanick Champoux wrote:
:>
:> # Rick Delaney (58chr)
:> @0,@1;push@{$foo{$_}},$_ for keys%foo;$"=",";print"@1;@0";
: When 5.6.1 comes out, this won't even need the first 6 characters. :-)
True. |)
hmmm..
What would be nice would be a new pragma, 'use golf' that
would alias all those loooooong function names to something
a wee bit shorter. Something like 'push @a, sort reverse @b for @c'
would become 'p@a,s r@b f @c'. A kind of evil counterpart to
'use english'. :)
/Yanick
--
$_=qq/ evil'prank from"yet another Perl hacker."'/;
open from, ">-" and close to, "-<";
y,i,a,;'h! My poor little boat'; s'ank'int'o;'the sea';
'Alas, alas, she was not ready to sail th',eval;'ley of tears.';
------------------------------
Date: 7 Sep 2000 19:56:58 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Sorting again.
Message-Id: <8p9dgq$cvk$1@provolone.cs.utexas.edu>
In article <slrn8rfbj6.pkg.abigail@alexandra.foad.org>,
Abigail <abigail@foad.org> wrote:
>Brendon Caligari (bcaligari@my-deja.com) wrote on MMDLXIV September
>MCMXCIII in <URL:news:8p7mha$uf$1@nnrp1.deja.com>:
>It already does so with quicksort. Mergesort does use more memory than
>quicksort, but throwing memory at a problem is a typical Perl thing to do.
Has anyone thought about just incorporating several sorts into the Perl
distribution as loadable modules? That way, there's no need to discuss
which is best because you can just implement several good ones and let
the user choose.
Personally, I'd like to see a bucket sort or radix sort, but that would
only be feasible if multiple sorts are allowed, since these sorts can't
be used in all cases.
- Logan
------------------------------
Date: Thu, 7 Sep 2000 22:51:59 GMT
From: "John P. Linderman" <jpl@research.att.com>
Subject: Re: Stable sorting
Message-Id: <39B81C0F.8A28CF53@research.att.com>
Uri Guttman wrote:
> >>>>> "RJ" == Russ Jones <russ_jones@rac.ray.com> writes:
>
> RJ> Abigail wrote:
> >>
> >> $$ > Perl 5.7.0 uses merge sort to implement sort(). Merge sort is stable.
>
> RJ> I'd hope that any implementation of "sort" in Perl would not preserve
> RJ> the order of equally keyed records by default, although I'd like to
> RJ> see it as an option. In most cases, though, it would be a solution
> RJ> looking for a problem that just didn't exist.
>
> the merge sort algorithm itself is stable. you can't turn that feature
> off. it doesn't have any effect on efficiency.
There are lots of ways to implement merge sort. Stability isn't automatic.
For example, if one starts out by looking for natural runs in the input,
and one happens across something like
5 4 3 2 2 1 0
that would be a single, reversed, run, if stability were unimportant,
but it is two runs, 5 4 3 2 and 2 1 0, if you are worrying about stability,
because the first 2 must compare low to the second one if stability
matters. When I first saw Peter Mcilroy's merge sort code
(which now underlies the 5.7.0 sort builtin), it *wasn't* stable.
It moved from unstable, to stability as an option, to stabilty
by default, as it matured. My comment in the new sort code:
/*
** Things that were once options have been hotwired
** to values suitable for this use. In particular, we'll always
** initialize looking for natural runs, we'll always produce stable
** output, and we'll always do Peter Mcilroy's binary merge.
*/
reflects the optional status when I first recoded Peter's sort.
There are also implications in the general merge phase.
When merging equal elements from two lists, if you can
ignore stability, you can ignore which list is which.
Stability forces you to keep track of which list came first,
so ties can be broken appropriately. There are code complexity
and performance penalties for stability, at least as implemented
in 5.7.0.
That being said, the impact on complexity and performance
is pretty small. This is much less true of the impact
(on performance at least) of qsort. The typical qsort's
*only* opportunity to outperform N log N is on duplicated
keys. If things are stable, there *are* no duplicated keys.
(I think) I'm beginning to see some important circumstances
where qsort outperforms merge sort, but the circumstances
have nothing to do with stability, and much to do with
hardware caches. But I reserve the right to be wrong :-) -- jpl
------------------------------
Date: Thu, 07 Sep 2000 22:05:42 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <srg49m2pljn182@corp.supernews.com>
avast (avast@hortonsbay.com) wrote:
[snip]
: Others, unfortunately, still seem overly obtuse and inscrutable to me.
: For example the line:
:
: my @fields = split /,\s+/ => $fields;
:
: can be re-written as:
:
: $fields =~ s/ +//g;
: @fields = split /,/,$fields;
Yes, but to what end? Yours makes a single logical operation ("Split on
commas which are follwed by whitespace") into two operations, one of which
needlessly modifies the source string. How is this superior to just
writing the split so that it actually encodes the split criterion
directly?
: Even more inscrutable to me is the following:
:
: /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
: @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
:
: It'll probably take a good hour or so for me to puzzle this one out.
This is a bit idiomatic, but you'll get used to it. 'and' is being used
here as a compact form of if-then, suitable (since it's an expression) for
being iterated via terminal while. Read it as "for each line in DATA, if
the big hairy pattern matches, use the resulting match variables to
populate the depths of a data structure."
: Again, is this type of compactness something to strive for or is it
: merely a personal preference on the part of the author? Are there
: useful lessons hidden here?
In general, compact code is quickly readable by other experienced users
(extremes like JAPH sigs obviously excepted).
: Most inscruatble of all is:
:
: {
: local ($,, $\) = ("\t", "\n");
: print @fields, "\n";
: print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
: }
:
: The use of the seemingly bare curly braces is something I've not see
: before.
These simply establish a block, just like they do when they indicate what
statements an if or while or whatever will apply to. Here they are used
to limit the scope of the localization that follows.
: Additionally, the use of "local" instead of "my" here seems
: significant but I have no idea why it's used in this case. I know
: that "local" saves the values of it's arguments on a run time stack
: and puts them back when the script leaves the "block" containing
: "local". In the above case I don't see the significance in doing
: this.
The special variables like $, and $\ are all globals, not lexicals. To
override their values (and have the change effect anything) you need to
localize them rather than creating a local lexical synonym.
: I'm sure that there's a good reason but my noviceness is
: keeping the scales firmly attached to my eyeballs at this point. I'm
: not even sure where to go to look for the answer (not _what_ local
: is but _when_ to use it).
You use local to temporarily override the values of global variables, of
which the various special variables are good examples. Another case where
you might do this with your own globals is if you wanted the scope of a
change to extend into called subroutines, whicy 'my' does not do.
: This kind of stuff is extremely depressing to me in that what I think
: I know about perl and how to use it seems horribly trivial and
: mundane.
Don't be depressed, all it takes is time and practice to get into the
'deep' stuff. If you're solving your problems with the amount of Perl you
know, then you are using Perl effectively.
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Every force evolves a form."
| - Shriekback
------------------------------
Date: 7 Sep 2000 15:28:29 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39b8168d@news.victoria.tc.ca>
avast (avast@hortonsbay.com) wrote:
: In article <MPG.14205c5c8ef332e98ad2f@nntp.hpl.hp.com>,
: Larry Rosler <lr@hpl.hp.com> wrote:
: <snip>
: > Here is some compactly-writtten code to play with. I don't have time to
: > write a detailed explanation. Breaking it down into beginner-level code
: > may be instructive as an exercise.
: >
: > #!/usr/bin/perl -w
: > use strict;
: >
: > my %users;
: > chomp(my $fields = <DATA>);
: > my @fields = split /,\s+/ => $fields;
: >
: > /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
: > @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
: >
: > {
: > local ($,, $\) = ("\t", "\n");
: > print @fields, "\n";
: > print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
: > }
: > __END__
: > user, password, alias
: > Rod, abc, "rod@hotmail.com"
: > Jane, def, "jane@excite.com"
: > Freddy, ghi, "freddy@bigfoot.com"
: As a perl (or is it Perl?) novice I find it extremely instructive to
: analyze the code of highly experienced pratitioners. Larry's above
(snip)
: readability and expressiveness. Others, unfortunately, still seem
: overly obtuse and inscrutable to me. For example the line:
: my @fields = split /,\s+/ => $fields;
: can be re-written as:
: $fields =~ s/ +//g;
: @fields = split /,/,$fields;
No it can't. You're removing white space that wasn't originally removed,
and potentially splitting into more fields.
: Larry's example uses one line instead of two but to what end? My
: assumption is that Larry is doing this for a good reason and the
: reason probably has to do with speed.
speed maybe a nice extra reason, but the real reason (well I can't read
Larry's mind but I would feel sure) is that the original line correctly
described the syntax of the line being split. "The fields are seperated
by commas that are followed by some white space".
Question number 1: Is it OK to
: err on the side of clarity (i.e., two lines) or should one ultimately
: strive for the compactness of Larry's example?
Its always OK to err on the side of clarity, assuming the program still
functions correctly.
: Even more inscrutable to me is the following:
: /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
: @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
Pasal programmers claim that I = I + 1 is clearer than I++; Most C
programmers would disagree. They would claim that I++ is clearer. Not
only is it shorter to read but it more correctly describes the operation
being performed -- the _original_ value is _incremented_, as opposed to a
_new_ value being _calculated_ and _assigned_.
And so too with Perl. The statement reads...
try to match the current line and then save the extracted fields
using the first field (presumably the "username") as the key to
the saved data -- while there are lines to read.
It may take a minute to determine "exactly" what's happening, but the
general intent is clear at a glance if you program in Perl. I think most
Perl programmers would (correctly) assume that fields from valid data
lines are being saved with the user name as the key. (Badly chosen
variables names would of course obfuscate this code very easily.)
: It'll probably take a good hour or so for me to puzzle this one out.
: Again, is this type of compactness something to strive for or is it
: merely a personal preference on the part of the author? Are there
: useful lessons hidden here?
Well I'm not sure I wish for quite so much brevity myself, but on the
other hand when the program as a whole is much shorter then it can be
easier to understand what is does than a longer program with clearer
individual parts.
: Most inscruatble of all is:
: {
: local ($,, $\) = ("\t", "\n");
: print @fields, "\n";
: print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
: }
: The use of the seemingly bare curly braces is something I've not see
They appear everywhere in Perl, and they're no barer than the braces in
some of the lines quoted above.
: before. Additionally, the use of "local" instead of "my" here seems
: significant but I have no idea why it's used in this case. I know
$, and $\ are global variables, of which Perl has a bunch. Since your
code doesn't "own" these variables, you have to use local, (after all,
you couldn't say "those variables are _mine_" could you?)
: that "local" saves the values of it's arguments on a run time stack
: and puts them back when the script leaves the "block" containing
: "local". In the above case I don't see the significance in doing
: this. I'm sure that there's a good reason but my noviceness is
: keeping the scales firmly attached to my eyeballs at this point. I'm
: not even sure where to go to look for the answer (not _what_ local
: is but _when_ to use it).
On the NT machine I'm using at this moment, I would look for answers in
C:\Perl\lib\Pod\*.pod
: This kind of stuff is extremely depressing to me in that what I think
: I know about perl and how to use it seems horribly trivial and
: mundane. My ultimate goal is to be able to write stuff like the
: above code without even thinking about it. I want it to be second
: nature. My problem right now is I'm not sure how to get there. Any
: advice would be greatly appreciated.
: Avast
--
------------------------------
Date: 07 Sep 2000 23:46:24 GMT
From: abigail@foad.org (Abigail)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <slrn8rga4k.vlt.abigail@alexandra.foad.org>
avast (avast@hortonsbay.com) wrote on MMDLXIV September MCMXCIII in
<URL:news:39b7f250.27089060@news.mco.edu>:
-: In article <MPG.14205c5c8ef332e98ad2f@nntp.hpl.hp.com>,
-: Larry Rosler <lr@hpl.hp.com> wrote:
-: <snip>
-: > Here is some compactly-writtten code to play with. I don't have time to
-: > write a detailed explanation. Breaking it down into beginner-level code
-: > may be instructive as an exercise.
-: >
-: > #!/usr/bin/perl -w
-: > use strict;
-: >
-: > my %users;
-: > chomp(my $fields = <DATA>);
-: > my @fields = split /,\s+/ => $fields;
-: >
-: > /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
-: > @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
-: >
-: > {
-: > local ($,, $\) = ("\t", "\n");
-: > print @fields, "\n";
-: > print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
-: > }
-: > __END__
-: > user, password, alias
-: > Rod, abc, "rod@hotmail.com"
-: > Jane, def, "jane@excite.com"
-: > Freddy, ghi, "freddy@bigfoot.com"
-:
-: As a perl (or is it Perl?) novice I find it extremely instructive to
-: analyze the code of highly experienced pratitioners. Larry's above
-: example is a good one. Coming from C and COBOL (please don't laugh),
-: however, I continue to have some difficulty with perl idioms. Some of
-: these idioms (e.g., foreach my $thingy (@somearray) ) are clearly
-: superior to C's more clunky "for (x=0;x<something;x++)" both in
-: readability and expressiveness. Others, unfortunately, still seem
-: overly obtuse and inscrutable to me. For example the line:
-:
-: my @fields = split /,\s+/ => $fields;
-:
-: can be re-written as:
-:
-: $fields =~ s/ +//g;
-: @fields = split /,/,$fields;
No, it can't. For instance, if
$fields = "foo bar, baz";
Larry's code results in:
@fields = ("foo bar", "baz");
while your rewrite results in:
@fields = ("foobar", "baz");
You lost the spaces in all your fields!
Not to mention that Larry's code would strip leading tabs, and would not
split a field containing a comma.
-: Larry's example uses one line instead of two but to what end? My
-: assumption is that Larry is doing this for a good reason and the
-: reason probably has to do with speed. Question number 1: Is it OK to
-: err on the side of clarity (i.e., two lines) or should one ultimately
-: strive for the compactness of Larry's example?
Clarity usually wins, but clarity is irrelevant when replacing code with
code that gives a different behaviour. At most one of them is correct.
Correctness, however, *always* wins, and it's non-tradeable. One can
trade clarity for efficiency, or memory for run-time, but you can't
trade in correctness.
-: Even more inscrutable to me is the following:
-:
-: /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
-: @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
-:
-: It'll probably take a good hour or so for me to puzzle this one out.
-: Again, is this type of compactness something to strive for or is it
-: merely a personal preference on the part of the author? Are there
-: useful lessons hidden here?
-:
-: Most inscruatble of all is:
-:
-: {
-: local ($,, $\) = ("\t", "\n");
-: print @fields, "\n";
-: print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
-: }
-:
-: The use of the seemingly bare curly braces is something I've not see
-: before.
Odd. One would expect a C programmer to have seen bare braces. For exactly
the same purpose as is used here: creating a lexical scope.
-: Additionally, the use of "local" instead of "my" here seems
-: significant but I have no idea why it's used in this case.
Because you cannot my() punctuation variables.
-: I know
-: that "local" saves the values of it's arguments on a run time stack
-: and puts them back when the script leaves the "block" containing
-: "local". In the above case I don't see the significance in doing
-: this. I'm sure that there's a good reason but my noviceness is
-: keeping the scales firmly attached to my eyeballs at this point. I'm
-: not even sure where to go to look for the answer (not _what_ local
-: is but _when_ to use it).
It's because the values of $, and $\ impact *EVERY* print in the entire
program. By localizing the values of $, and $\, the above code will not
influence any other print in the program.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
------------------------------
Date: Fri, 08 Sep 2000 00:25:02 GMT
From: avast@hortonsbay.com (Avast)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39b8300a.32375960@news.accesstoledo.com>
On Thu, 7 Sep 2000 14:58:24 -0700, Larry Rosler <lr@hpl.hp.com> wrote:
<snip>
>+ > Here is some compactly-writtten code to play with. I don't have
>+ > time to write a detailed explanation.
>
>Apparently I will end up doing just that! :-)
And I thank you for that! :-)
<snip>
>perlfaq1: "What's the difference between ``perl'' and ``Perl''?"
I shall read it!
<snip>
>+ my @fields = split /,\s+/ => $fields;
>+
>+ can be re-written as:
>+
>+ $fields =~ s/ +//g;
>+ @fields = split /,/,$fields;
>It has to do with dealing with the particular problem. The data shown
>use a comma followed by a space as the field separator. For all I know,
>some day one of the data fields would include an interior space, which
>your first line of code would wipe out.
>
>As for the generalization from one space to a sequence of whitespace
>characters, that allows for my having misread the space for a tab, or
>whatever. Call it 'Defensive Coding', which adds robustness to the code
>at little or no expense.
Excellent point. I hadn't thought of that, taking only the data that
was given in the example. D'Oh!
<snip>
>+ /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
>+ @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
>This is personal preference, or bravado.
Well, you're allowed. That's part of the reason I (and am sure
others) lurk here!
>+ Most inscruatble of all is:
>+
>+ {
>+ local ($,, $\) = ("\t", "\n");
>+ print @fields, "\n";
>+ print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
>+ }
>One cannot use 'my' for Perl special variables.
Aaaaah. Thanks for pointing that out. Pretty cool!
Thanks again for your response. I enjoy your comments as well as
examples. They're a great way to learn.
Avast
------------------------------
Date: 08 Sep 2000 00:32:06 GMT
From: abigail@foad.org (Abigail)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <slrn8rgcqc.vlt.abigail@alexandra.foad.org>
Malcolm Dew-Jones (yf110@vtn1.victoria.tc.ca) wrote on MMDLXIV September
MCMXCIII in <URL:news:39b8168d@news.victoria.tc.ca>:
""
"" Pasal programmers claim that I = I + 1 is clearer than I++;
Really? A strange breed of Pascal programmers. I'd think they prefer
I = inc (I);
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
------------------------------
Date: Fri, 08 Sep 2000 00:33:29 GMT
From: avast@hortonsbay.com (Avast)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39b83211.32895141@news.accesstoledo.com>
On Thu, 07 Sep 2000 22:05:42 GMT, cberry@cinenet.net (Craig Berry)
wrote:
<snip>
>: $fields =~ s/ +//g;
>: @fields = split /,/,$fields;
>
>Yes, but to what end? Yours makes a single logical operation ("Split on
>commas which are follwed by whitespace") into two operations, one of which
>needlessly modifies the source string. How is this superior to just
>writing the split so that it actually encodes the split criterion
>directly?
Oops. I never meant to imply it was superior. The above is the way I
saw the operation Larry coded. You are, of course, correct in your
assessment. Thanks!!!
<snip>
>In general, compact code is quickly readable by other experienced users
>(extremes like JAPH sigs obviously excepted).
Yeah, but the JAPHs are fun to run. I especially like the one of
Abigail's that prints "Just Another Perl Hacker" backwards and then
reverses it slowly letter by letter. Pretty cool!
<snip>
>Don't be depressed, all it takes is time and practice to get into the
>'deep' stuff. If you're solving your problems with the amount of Perl you
>know, then you are using Perl effectively.
Thanks for the encouragement. I'll keep hiding in the bushes for a
while longer.
Avast
------------------------------
Date: Fri, 08 Sep 2000 00:43:13 GMT
From: avast@hortonsbay.com (Avast)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39b8343e.33452431@news.accesstoledo.com>
On 07 Sep 2000 23:46:24 GMT, abigail@foad.org (Abigail) wrote:
<snip>
> For example the line:
>-:
>-: my @fields = split /,\s+/ => $fields;
>-:
>-: can be re-written as:
>-:
>-: $fields =~ s/ +//g;
>-: @fields = split /,/,$fields;
>
>No, it can't. For instance, if
>
> $fields = "foo bar, baz";
>
>Larry's code results in:
>
> @fields = ("foo bar", "baz");
>
>while your rewrite results in:
>
> @fields = ("foobar", "baz");
>
>You lost the spaces in all your fields!
Yup. I see that. Good point.
>Not to mention that Larry's code would strip leading tabs, and would not
>split a field containing a comma.
And that too. Another good point.
>-: Larry's example uses one line instead of two but to what end? My
>-: assumption is that Larry is doing this for a good reason and the
>-: reason probably has to do with speed. Question number 1: Is it OK to
>-: err on the side of clarity (i.e., two lines) or should one ultimately
>-: strive for the compactness of Larry's example?
>
>Clarity usually wins, but clarity is irrelevant when replacing code with
>code that gives a different behaviour. At most one of them is correct.
>
>Correctness, however, *always* wins, and it's non-tradeable. One can
>trade clarity for efficiency, or memory for run-time, but you can't
>trade in correctness.
Agreed. Absolutely.
<snip>
>-: Most inscruatble of all is:
>-:
>-: {
>-: local ($,, $\) = ("\t", "\n");
>-: print @fields, "\n";
>-: print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
>-: }
>-:
>-: The use of the seemingly bare curly braces is something I've not see
>-: before.
>
>Odd. One would expect a C programmer to have seen bare braces. For exactly
>the same purpose as is used here: creating a lexical scope.
Sorry, never ran into that before. It's weird all the stuff you can
do with only a sub-set of the language. I see the point, however.
Thanks!
>-: Additionally, the use of "local" instead of "my" here seems
>-: significant but I have no idea why it's used in this case.
>
>Because you cannot my() punctuation variables.
Yup. I see that too now.
BTW: I loved your JAPH with the backwards "Just Another ...." slowly
reversing itself. What made you think of that?? Pretty cool!
Thanks!!!!
Avast
------------------------------
Date: Fri, 08 Sep 2000 00:47:22 GMT
From: avast@hortonsbay.com (Avast)
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39b83698.34054252@news.accesstoledo.com>
On Thu, 07 Sep 2000 20:14:49 GMT, avast@hortonsbay.com (avast) wrote:
Just wanted to thank everyone who responed to my message. Learning
this stuff is certainly frustrating sometimes as I'm sure you'd all
agree, but having you fine folks on the other end certainly makes the
journey interesting.
Thanks again!!!
Avast
------------------------------
Date: Thu, 07 Sep 2000 23:37:25 GMT
From: interlocator@my-deja.com
Subject: two questions- help
Message-Id: <8p98rj$tkn$1@nnrp1.deja.com>
I'm not lazy, I'm studying but don't know the words to be able to find
these answers so I'll just describe my questions.
I need to pass the "user" from one script to another script for further
processing.
And,
I want to send two emails to the same person, one that has a thank you,
and a separate one that has the password. I can send one email using
sendmail, but when I try to send another right after it it errs.
Any help would be greatly appreciated, TYIA.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 08 Sep 2000 00:03:38 GMT
From: tim@degree.ath.cx (Tim Hammerquist)
Subject: Re: use strict: why?
Message-Id: <slrn8rgbu1.26k.tim@degree.ath.cx>
On Tue, 05 Sep 2000 13:04:35 GMT, Keith Calvert Ivey <kcivey@cpcug.org> wrote:
> The
> number of questions in the group is overwhelming, so it's a good
> idea to eliminate as many of the ones that can be easily
> answered by "use strict;" as possible, so that the answerers can
> help more people. Why is that a problem?
Not a thing.
--
-Tim Hammerquist <timmy@cpan.org>
I respectfully decline the invitation
to join your hallucination.
-- Dilbert
------------------------------
Date: Fri, 08 Sep 2000 00:25:14 GMT
From: tim@degree.ath.cx (Tim Hammerquist)
Subject: Re: use strict: why?
Message-Id: <slrn8rgd6f.26k.tim@degree.ath.cx>
Andrew Johnson <andrew-johnson@home.com> wrote:
> In article <slrn8r9b5b.1c7.tim@degree.ath.cx>,
> Tim Hammerquist <tim@degree.ath.cx> wrote:
> > `perldoc perlstyle`
> > The most important thing is to run your programs under the -w
> > flag at all times. You may turn it off explicitly for particular
> > portions of code via the `$^W' variable if you must. You should
> > also always run under `use strict' or know the reason why not.
> >
> > NB: "...or know the reason why not." Besides, the top of perlstyle
> > disclaims that these are only Larry's "guidelines" for maintainable code
> > not out-and-out rules.
>
> The "or know the reason why not" is the key element here. Many posters
> and lurkers on this NG are neophytes, and won't "know the reason why
> not" yet, so it makes very good sense to encourage the use of the
> strict pragma and -w.
Very much so.
> It strikes me that anyone who already knows the reason 'why not',
> needn't bother asking why people recommend it in the first place --
> they already know why it is a good idea, and they already know when
> they can safely ignore such advice.
I never asked why people recommend it. Especially in a newsgroup like
this, it's use is obvious. I asked why it's absence in a script is
labeled as an error.
--
-Tim Hammerquist <timmy@cpan.org>
God made the Idiot for practice, and then He made the School Board.
-- Mark Twain
------------------------------
Date: Fri, 08 Sep 2000 00:41:52 GMT
From: tim@degree.ath.cx (Tim Hammerquist)
Subject: Re: use strict: why?
Message-Id: <slrn8rge5m.26k.tim@degree.ath.cx>
On Tue, 05 Sep 2000 15:23:49 GMT, Ben Kennedy <bkennedy99@home.com> wrote:
> Considering that lexical variables are faster than global variables
This didn't sound right to me. I remember reading that lexical (my)
variables are faster than variables defined with the local keyword, but
never heard that lexicals are faster than globals. So I did research:
: Benchmark: timing 100000000 iterations of global, lexical...
: global: 170 wallclock secs (162.30 usr + 0.24 sys = 162.54 CPU)
: lexical: 180 wallclock secs (174.32 usr + -0.03 sys = 174.29 CPU)
(On Mandrake Linux 7.0, kernel 2.2.14-15mdk, perl 5.005_03)
Code:
: #!/usr/bin/perl -w
:
: use Benchmark;
:
: $global = 5;
: my $lex = 5;
:
: sub global_test {
: $global;
: }
:
: sub lexical_test {
: $lex;
: }
:
: timethese( 100_000_000, {
: lexical => \&lex_test,
: global => \&global_test
: } );
Of course, the sheer fact that I had to run 100 million iterations to
find a consistend noticeable difference in access time makes the
difference basically negligible. But at least one rumor's been struck
down.
--
-Tim Hammerquist <timmy@cpan.org>
I know I can quit smoking because I've done it a thousand times.
-- Mark Twain
------------------------------
Date: Thu, 07 Sep 2000 22:12:28 GMT
From: cfedde@u.i.sl3d.com (Chris Fedde)
Subject: Re: Where is the Perl Newbie or Begginers group?
Message-Id: <gpUt5.4$W3.171846144@news.frii.net>
In article <39A6C127.8B8561A@cwcom.nospam.net>, j <blah@cwcom.bkak.net> wrote:
>jason wrote:
>> sysnovice <gdonovanNOgdSPAM@jeffco.k12.co.us.invalid> wrote ..
>> >I am a Unix SysAd with no programming experience looking for
>
>I'm in the same boat as you Jason and lurk in this group picking up
>
I just wanted to point out a confusion with this post. Please don't
take it as a personal snub. It turns out that all the text that
<blah@cwcom.bkak.net> quoted was generated by
<gdonovanNOgdSPAM@jeffco.k12.co.us.invalid> and not Jason. It
takes a minute or two to look at the indentation level to understand
the flow of a thread on Usenet.
BTW, I applaud your proper use of quoting and conventional reply
formatting. Good Job! If your looking for a more complete treatment
of the expected standards of behavior read some of the regular
postings in the usenet group news.newusers.
This group _IS_ the right place for neophyte perl programmers to
pick up tips and advice from those with more experience. Welcome
and good hunting.
chris
--
chris fedde
303 773 9134
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 4253
**************************************
