[32357] in Perl-Users-Digest
Perl-Users Digest, Issue: 3624 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 27 16:09:24 2012
Date: Mon, 27 Feb 2012 13:09:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 27 Feb 2012 Volume: 11 Number: 3624
Today's topics:
Re: a question about efficiency <rweikusat@mssgmbh.com>
Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
Re: a question about efficiency (Seymour J.)
Re: a question about efficiency <hjp-usenet2@hjp.at>
Re: a question about efficiency (Seymour J.)
Re: a question about efficiency (Greg Bacon)
Re: a question about efficiency <rweikusat@mssgmbh.com>
Re: Constructing a value beforehand <hjp-usenet2@hjp.at>
Re: Constructing a value beforehand <hjp-usenet2@hjp.at>
given...when <kiuhnm03.4t.yahoo.it>
Re: given...when <ben@morrow.me.uk>
Re: given...when (Seymour J.)
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when <ben@morrow.me.uk>
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when (Tim McDaniel)
Re: given...when <kiuhnm03.4t.yahoo.it>
smart matching <kiuhnm03.4t.yahoo.it>
Re: tree to array of arrays <rvtol+usenet@xs4all.nl>
Re: use file::find to find files modified in last 5 day (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 26 Feb 2012 14:35:06 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a question about efficiency
Message-Id: <87obslek85.fsf@sapphire.mobileactivedefense.com>
gbacon@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> : Steele defines closure as 'function defined in a non-null lexical
> : environment'. Originally, I suggested to use the same definition for
> : Perl. But this definition cannot be used for Perl because it is not
> : possible to create a Perl subroutine which is outside of any lexical
> : environment aka 'outer scope'. And 'the implementation of
> : Perl_cv_clone' doesn't figure here at all: Irregardless of how
> : closures are implemented in Perl (meaning, even if there wasn't always
> : an outside link => Ben's posting), there's still always such an
> : outside environment when the subroutine is created.
>
> How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
> the outer lexical scope? Calling either of these representatives a
> closure dilutes the term to the point of meaninglessness.
I don't quite understand why you're hellbent on misunderstanding my
statement but I don't think that repeating it for a third time makes
any sense.
------------------------------
Date: Sun, 26 Feb 2012 15:43:58 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f4a452d$0$1389$4fafbaef@reader2.news.tin.it>
On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
> In<4f43d60b$0$1387$4fafbaef@reader2.news.tin.it>, on 02/21/2012
> at 06:36 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> Of course. What strikes me is that strange "for".
>
> See statement modifiers in perlsyn.
>
>> "Learning Perl" won't give me too many details until my fragile mind
>> is ready to assimilate them :)
>
> I found that it was easier to learn from "Programming Perl" than from
> "Learning Perl".
I'm about to finish studying "Learning Perl" and now I understand what
you mean.
The biggest flaw (*) of that book is that it never tells you the entire
story. The result is that I'm never sure of anything when I try to do
something a little more complex. For instance, whenever I try to craft
longer expressions (like in functional programming) I get syntax errors.
Then I start juggling with parentheses, commas, and so on until, by
trial-and-error, I get it right.
I don't know about you, but I'd like to get it right the first time
(well, at least I want to have a chance).
Kiuhnm
(*) Besides having too many footnotes... like this one.
------------------------------
Date: Sun, 26 Feb 2012 11:13:57 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: a question about efficiency
Message-Id: <4f4a5a45$14$fuzhry+tra$mr2ice@news.patriot.net>
In <TJCdnQEN38v8ANTSnZ2dnUVZ_s6dnZ2d@posted.hiwaay2>, on 02/25/2012
at 08:48 PM, gbacon@hiwaay.net (Greg Bacon) said:
>Can t we all just go back to EBCDIC?
Sure; which EBCDIC code page do you want? BTDT,GTS.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Sun, 26 Feb 2012 18:54:56 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: a question about efficiency
Message-Id: <slrnjkksfg.65r.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-25 23:35, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <slrnjkh9sl.8lm.hjp-usenet2@hrunkner.hjp.at>, on 02/25/2012
> at 10:19 AM, "Peter J. Holzer" <hjp-usenet2@hjp.at> said:
>>The usenet has been 8-bit clean almost since the beginning,
>
> RFC 977 leaves the question open; I don't know about UUCP. RFC 3977
> didn't come out until 2006, although it may well be that all deployed
> NNTP software was 8-bit clean by then.
C-News was 8-bit clean and it was released in 1987. By about 1990 it
almost completely replaced B-News (one of the last holdouts I remember
whas unido, which was a bit unfortunate since it was at a relatively big
German university, so it had ample opportunity for mangling umlauts).
EBCDIC hosts were more problematic: Not only were they not 8-bit clean,
they weren't even ASCII-clean. It was quite possible to find a usenet
posting in comp.lang.c where all the curly braces had been replaced by
other characters. Minix used a non-standard uuencode format which was
specially designed to survive the damage inflicted by ASCII-EBCDIC
gateways.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sun, 26 Feb 2012 17:40:24 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: a question about efficiency
Message-Id: <4f4ab4d8$1$fuzhry+tra$mr2ice@news.patriot.net>
In <slrnjkksfg.65r.hjp-usenet2@hrunkner.hjp.at>, on 02/26/2012
at 06:54 PM, "Peter J. Holzer" <hjp-usenet2@hjp.at> said:
>EBCDIC hosts were more problematic: Not only were they not 8-bit
>clean, they weren't even ASCII-clean.
Historically, the ASCII-EBCDIC translation in OS/360 and descendants
has been a dogs breakfast, so I'm not surprised.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Mon, 27 Feb 2012 08:43:36 -0600
From: gbacon@hiwaay.net (Greg Bacon)
Subject: Re: a question about efficiency
Message-Id: <4YCdnefM8dIFC9bSnZ2dnUVZ_jidnZ2d@posted.hiwaay2>
Rainer Weikusat wrote:
: Greg Bacon writes:
:
: > How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
: > the outer lexical scope? Calling either of these representatives a
: > closure dilutes the term to the point of meaninglessness.
:
: I don't quite understand why you're hellbent on misunderstanding my
: statement but I don't think that repeating it for a third time makes
: any sense.
I understand your statement just fine. You argued Steele’s
definition of closure is inapplicable to Perl because an outer
lexical environment exists at the point of creation.
This misses the forest for the trees. There is no *semantic*
difference between a function defined in a null lexical environment
and a function defined in a non-null but unreachable lexical
environment.
Greg
--
Men stumble over the truth from time to time, but most pick themselves
up and hurry off as if nothing happened.
-- Winston Churchill
------------------------------
Date: Mon, 27 Feb 2012 16:21:40 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a question about efficiency
Message-Id: <87linodz6z.fsf@sapphire.mobileactivedefense.com>
gbacon@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat wrote:
> : Greg Bacon writes:
> :
> : > How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
> : > the outer lexical scope? Calling either of these representatives a
> : > closure dilutes the term to the point of meaninglessness.
> :
> : I don't quite understand why you're hellbent on misunderstanding my
> : statement but I don't think that repeating it for a third time makes
> : any sense.
>
> I understand your statement just fine. You argued Steele’s
> definition of closure is inapplicable to Perl because an outer
> lexical environment exists at the point of creation.
This is a fact, there's generally no point in arguing about facts and
I certainly didn't try to.
> This misses the forest for the trees. There is no *semantic*
> difference between a function defined in a null lexical environment
> and a function defined in a non-null but unreachable lexical
> environment.
Further, despite your apparent desire for some kind of opponent,
beyond paraphrasing Steele's definition and coming to the conclusion
that it cannot be applied to Perl, I didn't post anything about *my*
opinion on this topic and actually, I don't even have an opinion about
it, at least not a clear-cut one. So, please feel free to argue (this
time really) about the relative merits of your definition of 'closure'
vs 'the definition someone else used' but please stop targetting me in
lieu of 'the guy with the other opinion' just because I'm coniently
located bystander.
------------------------------
Date: Sun, 26 Feb 2012 19:28:35 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Constructing a value beforehand
Message-Id: <slrnjkkuej.65r.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-25 15:18, Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
> On 2012-02-25 09:54, Peter J. Holzer wrote:
>
>> Perl sigils are no adequate substitute for the type prefixes in
>> Hungarian notations. Ignoring the fact that sigils don't even really
>> denote the type of a variable, there are only three of them, and even in
>> Systems Hungarian notation there are many more types which can be
>> distinguished:
>>
>> $bVerbose (Verbose is a boolean)
>> $nObjects (Objects is a count, i.e., a non-negative integer)
>> $fLength (Length is floating point number)
>> $bsParam (Param is a byte string, you still need to decode() it)
>> $csParam (Param is a character string)
>> $dogSpot (Spot is object of class Animals::Dog)
>
> In Perl, the sigil tells you about the structure (or count) of the
> variable (or expression).
I'm not sure whether you are agreeing or disagreeing with me, and
what this has to do with Hungarian notation.
> Perl is a strongly typed language. The datatype is in the operators.
I am aware that no two people agree on what "strongly typed" means
exactly, but I'm sure any definition of the term which includes Perl is
far from the mainstream.
> In p5p there is an auto-dereference thread, that wants to make
>
> push $array, @elements;
>
> be syntactic sugar for
>
> push @$array, @elements;
AFAIK that has already happened (5.14, I think).
> I opposed that, by pointing at the consequence that
>
> my $array = \@array;
>
> should then mean that $array contains 2 values:
> 1. the number of elements (to be returned in numeric context), and
> 2. the array-reference (to be returned in scalar context, specifically
> in auto-dereference context)
I don't see how that is a necessary consequence of allowing push to
autodereference its first parameter if is a scalar. Many builtins (and
user-defined subs, too) allow different parameters.
Even if autodereference is used in a lot more contexts, I think it's a
bit weird to say that $array contains the number of elements in case 1.
It makes more sense to say that $array is autodereferenced in a numeric
context, so that ($array + 0) is equivalent to (@$array + 0). That would
also be mostly backwards compatible I think, since a reference in
numeric context returns no usable value. I would want an exception for
== and !=, though: Comparing references for equality is useful.
Autodereferencing array references in string context is probably not a
good idea, however: Printing it as "ARRAY(0x8182818)" is too useful for
debugging.
> Be aware that in Perl it is normal for a variable to have multiple
> values at the same time.
Yes, although you can't currently have a reference and something else in
a scalar, and the different values you can put into a scalar (PV, NV,
IV) are normally just different representations of the same value
(yes, I know about Scalar::Util::dualvar).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sun, 26 Feb 2012 21:41:27 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Constructing a value beforehand
Message-Id: <slrnjkl67n.nno.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-25 08:54, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2012-02-23 18:18, Ben Morrow <ben@morrow.me.uk> wrote:
>> Quoth Xze <bhdistortion@gmail.com>:
>>> my $bVerbose = 0;
>>
>> Is this Hungarian notation? Perl variables already have sigils, they
>> don't need more prefixes.
>
> While I don't use Hungarian notation myself (I think it's ugly, the
> wrong way around, and not much use in practice), I disagree:
>
> Perl sigils are no adequate substitute for the type prefixes in
> Hungarian notations. Ignoring the fact that sigils don't even really
> denote the type of a variable, there are only three of them, and even in
> Systems Hungarian notation there are many more types which can be
> distinguished:
[...]
> If you go into Application Hungarian Notation (the original kind
> invented by Charles Simonyi, which I find a lot more useful than systems
> HN), you distinguish logical types, for example:
I just stumbled across this article by Joel Spolsky about Hungarian
notation (especially about the advantages of Apps Hungarian):
http://www.joelonsoftware.com/articles/Wrong.html
It's well worth reading and thinking about.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Mon, 27 Feb 2012 13:13:41 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: given...when
Message-Id: <4f4b7387$0$1386$4fafbaef@reader2.news.tin.it>
I've been experimenting a little with given...when (and variations). I'm
just curious to know what you think of the following code:
--->
#!/usr/bin/perl -w
use 5.010001;
given (1)
{
say "Guess the number (RETURN to give up)";
while (<>)
{
last when "\n";
say "You win!" when 5;
say "Wrong number"
}
say "Ah... you gave up!"
}
<---
Kiuhnm
------------------------------
Date: Mon, 27 Feb 2012 12:46:47 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: given...when
Message-Id: <nias19-q7r2.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> I've been experimenting a little with given...when (and variations). I'm
> just curious to know what you think of the following code:
>
> --->
> #!/usr/bin/perl -w
>
> use 5.010001;
>
> given (1)
> {
> say "Guess the number (RETURN to give up)";
> while (<>)
> {
> last when "\n";
> say "You win!" when 5;
> say "Wrong number"
> }
> say "Ah... you gave up!"
> }
I'd rather put it the other way round:
while (<>) {
given ($_) {
last when "\n";
say "You win!" when 5;
say "Wrong number";
}
}
say "Ah... you gave up!";
It's not just clearer, I'm also not entirely certain that the current
behaviour of that 'last when' is intended. when is supposed to (always)
break out of the innermost enclosing given, and to yell if it can't; I'm
not sure whether or not the fact that your last managed to get in first
would be considered a bug.
Ben
------------------------------
Date: Mon, 27 Feb 2012 10:24:47 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: given...when
Message-Id: <4f4ba040$5$fuzhry+tra$mr2ice@news.patriot.net>
In <nias19-q7r2.ln1@anubis.morrow.me.uk>, on 02/27/2012
at 12:46 PM, Ben Morrow <ben@morrow.me.uk> said:
>Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
>> {
>> say "Guess the number (RETURN to give up)";
>> while (<>)
>> {
>> last when "\n";
>> say "You win!" when 5;
>> say "Wrong number"
>> }
>> say "Ah... you gave up!"
>> }
Here the "when 5" breaks out of both the given and the loop.
>I'd rather put it the other way round:
That code doesn't seem to do the same thing.
> while (<>) {
> given ($_) {
> last when "\n";
> say "You win!" when 5;
> say "Wrong number";
> }
> }
> say "Ah... you gave up!";
Won't the "when 5" iterate the loop?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Mon, 27 Feb 2012 16:41:04 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4ba40f$0$1382$4fafbaef@reader2.news.tin.it>
On 2/27/2012 16:24, Shmuel (Seymour J.) Metz wrote:
> In<nias19-q7r2.ln1@anubis.morrow.me.uk>, on 02/27/2012
> at 12:46 PM, Ben Morrow<ben@morrow.me.uk> said:
>
>> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>
>>> {
>>> say "Guess the number (RETURN to give up)";
>>> while (<>)
>>> {
>>> last when "\n";
>>> say "You win!" when 5;
>>> say "Wrong number"
>>> }
>>> say "Ah... you gave up!"
>>> }
>
> Here the "when 5" breaks out of both the given and the loop.
>
>> I'd rather put it the other way round:
>
> That code doesn't seem to do the same thing.
>
>> while (<>) {
>> given ($_) {
>> last when "\n";
>> say "You win!" when 5;
>> say "Wrong number";
>> }
>> }
>> say "Ah... you gave up!";
>
> Won't the "when 5" iterate the loop?
You're right.
BTW, if someone asks you "Is there a way to break out (immediately) of a
nested loop without using labels?", you can show him or her this code:
--->
given (1)
{
while (1) {
while (1) {
while (1) {
while (1) {
say "just once!";
break }}}}
}
<---
Kiuhnm
------------------------------
Date: Mon, 27 Feb 2012 16:57:39 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: given...when
Message-Id: <39ps19-88v2.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <nias19-q7r2.ln1@anubis.morrow.me.uk>, on 02/27/2012
> at 12:46 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
>
> >> {
> >> say "Guess the number (RETURN to give up)";
> >> while (<>)
> >> {
> >> last when "\n";
> >> say "You win!" when 5;
> >> say "Wrong number"
> >> }
> >> say "Ah... you gave up!"
> >> }
>
> Here the "when 5" breaks out of both the given and the loop.
>
> >I'd rather put it the other way round:
>
> That code doesn't seem to do the same thing.
>
> > while (<>) {
> > given ($_) {
> > last when "\n";
> > say "You win!" when 5;
> > say "Wrong number";
> > }
> > }
> > say "Ah... you gave up!";
>
> Won't the "when 5" iterate the loop?
Yes, it will. Gah.
I have often thought I'd like 'when' to treat 'for' (with no explicit
variable) as a topicaliser, and 'last' out of the for loop instead of
insisting on 'break'ing out of a given; I guess I can now add while(<>)
to that wish. ISTM it would make perfect sense: both set $_ for the
duration of the block, just like given, they just get the value to set
it to from somewhere else.
Ben
------------------------------
Date: Mon, 27 Feb 2012 18:29:58 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4bbd95$0$1387$4fafbaef@reader1.news.tin.it>
On 2/27/2012 17:57, Ben Morrow wrote:
>
> Quoth Shmuel (Seymour J.) Metz<spamtrap@library.lspace.org.invalid>:
>> In<nias19-q7r2.ln1@anubis.morrow.me.uk>, on 02/27/2012
>> at 12:46 PM, Ben Morrow<ben@morrow.me.uk> said:
>>
>>> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>>
>>>> {
>>>> say "Guess the number (RETURN to give up)";
>>>> while (<>)
>>>> {
>>>> last when "\n";
>>>> say "You win!" when 5;
>>>> say "Wrong number"
>>>> }
>>>> say "Ah... you gave up!"
>>>> }
>>
>> Here the "when 5" breaks out of both the given and the loop.
>>
>>> I'd rather put it the other way round:
>>
>> That code doesn't seem to do the same thing.
>>
>>> while (<>) {
>>> given ($_) {
>>> last when "\n";
>>> say "You win!" when 5;
>>> say "Wrong number";
>>> }
>>> }
>>> say "Ah... you gave up!";
>>
>> Won't the "when 5" iterate the loop?
>
> Yes, it will. Gah.
>
> I have often thought I'd like 'when' to treat 'for' (with no explicit
> variable) as a topicaliser, and 'last' out of the for loop instead of
> insisting on 'break'ing out of a given; I guess I can now add while(<>)
> to that wish. ISTM it would make perfect sense: both set $_ for the
> duration of the block, just like given, they just get the value to set
> it to from somewhere else.
But then you would need an extra "given" to mimic an if-elsif or a
switch inside a for loop. As far as I know,
for() { when }
is a sort of syntactic sugar for
for() { given() { when ... }}
Kiuhnm
------------------------------
Date: Mon, 27 Feb 2012 19:32:15 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: given...when
Message-Id: <jiglnv$kbf$1@reader1.panix.com>
In article <4f4b7387$0$1386$4fafbaef@reader2.news.tin.it>,
Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>I've been experimenting a little with given...when (and variations). I'm
>just curious to know what you think of the following code:
>
>--->
>#!/usr/bin/perl -w
>
>use 5.010001;
>
>given (1)
>{
> say "Guess the number (RETURN to give up)";
> while (<>)
> {
> last when "\n";
> say "You win!" when 5;
> say "Wrong number"
> }
> say "Ah... you gave up!"
>}
As a side note: you can omit a semicolon just before the end of a
statement block, but I think it's better to always include it.
After you add or remove an item from a sequence and then do a diff in
source control, the diff will show only the line(s) that changed, not
including a preceding line when a separator was added.
Trailing semicolons are so common that I had to look up Perl syntax to
make sure that they can indeed be omitted.
My orkplace requires trailing semicolons, and also commas at the end
of each list item.
I don't know whether Perl has interesting cases where it fails
silently if you omit a semicolon -- that is, omitting a semicolon
does not cause a syntax error and also changes the behavior.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 27 Feb 2012 21:02:24 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4be14f$0$1386$4fafbaef@reader2.news.tin.it>
On 2/27/2012 20:32, Tim McDaniel wrote:
> As a side note: you can omit a semicolon just before the end of a
> statement block, but I think it's better to always include it.
> After you add or remove an item from a sequence and then do a diff in
> source control, the diff will show only the line(s) that changed, not
> including a preceding line when a separator was added.
> Trailing semicolons are so common that I had to look up Perl syntax to
> make sure that they can indeed be omitted.
> My orkplace requires trailing semicolons, and also commas at the end
> of each list item.
IMHO, that's a misconception. A semicolon is an "end of statement" in C
and C-like languages, but a "statement separator" in Perl.
I suspect that Perl turns a blind eye when you write the extra semicolon
and not when you omit that.
Kiuhnm
------------------------------
Date: Mon, 27 Feb 2012 18:14:07 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: smart matching
Message-Id: <4f4bb9de$0$1385$4fafbaef@reader1.news.tin.it>
I was doing an odd exercise that asks to perform some task by only using
"smart matching".
But then the solution uses
when (! /\A\d+\Z/) ...
Isn't that dumb matching?
I would use
when (0 ~~ ($_ ~~ /\A\d+\Z/)) ...
The solution also uses
my @empty;
when (@list ~~ @empty) ...
saying that we could just use @list in scalar context, but we have to
use smart matching.
What about
when (0 ~~ !!@list) ...
?
Kiuhnm
------------------------------
Date: Sun, 26 Feb 2012 10:36:04 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: tree to array of arrays
Message-Id: <4f49fd05$0$6898$e4fe514c@news2.news.xs4all.nl>
On 2012-02-25 22:31, George Mpouras wrote:
> split /\//, $_
You can write that as "split m{/}".
Pretty hey?
--
Ruud
------------------------------
Date: Sun, 26 Feb 2012 10:52:38 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <86ehth5sw9.fsf@red.stonehenge.com>
>>>>> "STD" == STD <mikesolomon40@googlemail.com> writes:
STD> I have written a script to find files
STD> I now want to be able to pass it a days parameter and only show files
STD> modified in the last x days
STD> How do I do this
Check out my File::Finder in the CPAN which has an interface that mimics
find(1) very closely.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3624
***************************************
