[32358] in Perl-Users-Digest
Perl-Users Digest, Issue: 3625 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 28 18:10:17 2012
Date: Tue, 28 Feb 2012 15:09:09 -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 Tue, 28 Feb 2012 Volume: 11 Number: 3625
Today's topics:
Re: a question about efficiency <tadmc@seesig.invalid>
Re: a question about efficiency (Seymour J.)
Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
and regexes? <pengyu.ut@gmail.com>
Re: and regexes? <ben@morrow.me.uk>
Re: given...when <kst-u@mib.org>
Re: given...when <ben@morrow.me.uk>
Re: given...when <ben@morrow.me.uk>
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when (Seymour J.)
Re: given...when (Tim McDaniel)
Re: given...when <willem@toad.stack.nl>
Re: given...when <ben@morrow.me.uk>
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when (Seymour J.)
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 28 Feb 2012 14:10:25 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: a question about efficiency
Message-Id: <slrnjkqda9.bdb.tadmc@tadbox.sbcglobal.net>
Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
>> 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.
A reference book (eg. Programming Perl) should tell you then entire story.
A tutorial book (eg. Learning Perl) should tell you the essential parts
of the story without myriad sidetrips into the "exceptions" (which Perl
is famous for).
Each is the Right Tool in different situatuions.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Tue, 28 Feb 2012 17:08:40 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: a question about efficiency
Message-Id: <4f4d5068$20$fuzhry+tra$mr2ice@news.patriot.net>
In <slrnjkqda9.bdb.tadmc@tadbox.sbcglobal.net>, on 02/28/2012
at 02:10 PM, Tad McClellan <tadmc@seesig.invalid> said:
>A tutorial book (eg. Learning Perl) should tell you the essential
>parts
I have yet to see a tutorial that covered what I considered the
essential parts. That's why I prefer learning from a reference,
although poor indexing may make it awkward.
--
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: Tue, 28 Feb 2012 23:44:42 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f4d58d9$0$1384$4fafbaef@reader2.news.tin.it>
On 2/28/2012 21:10, Tad McClellan wrote:
> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
>
>>> 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.
>
>
> A reference book (eg. Programming Perl) should tell you then entire story.
>
> A tutorial book (eg. Learning Perl) should tell you the essential parts
> of the story without myriad sidetrips into the "exceptions" (which Perl
> is famous for).
>
> Each is the Right Tool in different situatuions.
Let's put it this way: "Learning Perl" is too gentle and forgiving.
Kiuhnm
------------------------------
Date: Tue, 28 Feb 2012 10:07:32 -0800 (PST)
From: Peng Yu <pengyu.ut@gmail.com>
Subject: and regexes?
Message-Id: <90912bdb-8ff8-428e-84ba-8e86592a6fd7@p7g2000yqk.googlegroups.com>
Suppose that I have two regexs, I can use | to or them. Is there a way
to and them? Thanks!
------------------------------
Date: Tue, 28 Feb 2012 19:03:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: and regexes?
Message-Id: <c0lv19-jrl.ln1@anubis.morrow.me.uk>
Quoth Peng Yu <pengyu.ut@gmail.com>:
> Suppose that I have two regexs, I can use | to or them. Is there a way
> to and them? Thanks!
Be more specific. There are many ways to 'and' regexes, which is why
there isn't a single operator.
Do you want the matches to happen one after another, or do you want them
both to start at the same point? If the latter, do you want to insist
that both patterns matched the same text? If not, where should
subsequent parts of the pattern pick up the match?
I suspect that whatever it is you're trying to do, the (?=) lookahead
construction is what you need to do it.
Ben
------------------------------
Date: Mon, 27 Feb 2012 13:19:01 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: given...when
Message-Id: <lnhayc7z5m.fsf@nuthaus.mib.org>
Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
> 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!"
> }
> <---
perl 5.10.1 reports syntax errors:
syntax error at foo.pl line 10, near "last when"
syntax error at foo.pl line 11, near ""You win!" when"
foo.pl had compilation errors.
5.12 accepts it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 27 Feb 2012 22:32:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: given...when
Message-Id: <nsct19-6r1.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> On 2/27/2012 17:57, Ben Morrow wrote:
> >
> > 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 ... }}
You're right, it *does* already work with for. I hadn't realised that.
OK, I want while (<>) to work like that, too. If that were the case your
original post would work correctly, with no dubious constructions,
without any 'given' at all.
Ben
------------------------------
Date: Mon, 27 Feb 2012 22:42:50 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: given...when
Message-Id: <agdt19-6r1.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.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.
You're both wrong :). The parser insists on a semicolon to terminate
every statement, but the lexer inserts a semicolon before the } at the
end of a block and before the end of every file. Since the null
statement is explicitly allowed, this has the effect of making the semi
optional at the end of a scope.
Incidentally, this *also* happens inside the {} used for hash-derefs.
That's why perly.y has got productions like
subscripted: ...
| scalar '{' expr ';' '}'
with a completely unnecessary semicolon. Of course, in this case there
has to be *exactly* one, so you can't add extra semis inside a hash
subscript and get away with it.
Ben
------------------------------
Date: Mon, 27 Feb 2012 23:49:16 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4c086b$0$1378$4fafbaef@reader2.news.tin.it>
On 2/27/2012 23:32, Ben Morrow wrote:
>
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> On 2/27/2012 17:57, Ben Morrow wrote:
>>>
>>> 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 ... }}
>
> You're right, it *does* already work with for. I hadn't realised that.
> OK, I want while (<>) to work like that, too. If that were the case your
> original post would work correctly, with no dubious constructions,
> without any 'given' at all.
I'll second that.
Kiuhnm
------------------------------
Date: Tue, 28 Feb 2012 00:45:09 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4c1599$0$1382$4fafbaef@reader1.news.tin.it>
On 2/27/2012 23:42, Ben Morrow wrote:
>
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.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.
>
> You're both wrong :). The parser insists on a semicolon to terminate
> every statement, but the lexer inserts a semicolon before the } at the
> end of a block and before the end of every file. Since the null
> statement is explicitly allowed, this has the effect of making the semi
> optional at the end of a scope.
>
> Incidentally, this *also* happens inside the {} used for hash-derefs.
> That's why perly.y has got productions like
>
> subscripted: ...
> | scalar '{' expr ';' '}'
>
> with a completely unnecessary semicolon. Of course, in this case there
> has to be *exactly* one, so you can't add extra semis inside a hash
> subscript and get away with it.
Thanks for the interesting explanation!
I think I took a footnote too literally:
"The semicolon is really a statement separator, not a statement terminator."
The first thing I tried after your explanation was
{$_ = $}
Guess the lexer is not that stupid!
Kiuhnm
------------------------------
Date: Tue, 28 Feb 2012 09:51:32 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: given...when
Message-Id: <4f4ce9f4$12$fuzhry+tra$mr2ice@news.patriot.net>
In <agdt19-6r1.ln1@anubis.morrow.me.uk>, on 02/27/2012
at 10:42 PM, Ben Morrow <ben@morrow.me.uk> said:
>You're both wrong :). The parser insists on a semicolon to
>terminate every statement, but the lexer inserts a semicolon
>before the } at the end of a block and before the end of
>every file.
That's an implementation issue; the lexer is part of the
implimentation.
--
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: Tue, 28 Feb 2012 17:23:48 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: given...when
Message-Id: <jij2j3$1u$1@reader1.panix.com>
In article <agdt19-6r1.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Kiuhnm <kiuhnm03.4t.yahoo.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.
>
>You're both wrong :). The parser insists on a semicolon to terminate
>every statement, but the lexer inserts a semicolon before the } at the
>end of a block and before the end of every file.
From the point of view of a coder, what the lexer or parser does
internally is not of interest. When coding, you can look at Perl
either of two ways:
- semicolon is a statement separator but, because a null statement is
valid and has no result, you can include an extra semicolon at the
end of a block
- semicolon is a statement terminator but you can omit the semicolon
at the end of each block
No matter which way you express it, it produces the same results.
As far as I've seen, in practice, people tend to have a trailing
semicolon at the end of major blocks like sub, if, for, et cetera, but
omit the trailing semicolon in small blocks like map, grep, sort, and
short evals.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 28 Feb 2012 18:30:02 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: given...when
Message-Id: <slrnjkq79a.2dh4.willem@toad.stack.nl>
Tim McDaniel wrote:
) From the point of view of a coder, what the lexer or parser does
) internally is not of interest. When coding, you can look at Perl
) either of two ways:
)
) - semicolon is a statement separator but, because a null statement is
) valid and has no result, you can include an extra semicolon at the
) end of a block
)
) - semicolon is a statement terminator but you can omit the semicolon
) at the end of each block
)
) No matter which way you express it, it produces the same results.
)
) As far as I've seen, in practice, people tend to have a trailing
) semicolon at the end of major blocks like sub, if, for, et cetera, but
) omit the trailing semicolon in small blocks like map, grep, sort, and
) short evals.
I usually leave out the trailing semicolon when the closing brace
is on the same line, as I would with the trailing comma in lists.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Tue, 28 Feb 2012 18:56:54 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: given...when
Message-Id: <mkkv19-jrl.ln1@anubis.morrow.me.uk>
Quoth Willem <willem@toad.stack.nl>:
> Tim McDaniel wrote:
> ) From the point of view of a coder, what the lexer or parser does
> ) internally is not of interest. When coding, you can look at Perl
> ) either of two ways:
You and Shmuel are right, of course. I just think the internal
implementation is interesting. I don't *think* there are any cases where
the internals show through.
> ) As far as I've seen, in practice, people tend to have a trailing
> ) semicolon at the end of major blocks like sub, if, for, et cetera, but
> ) omit the trailing semicolon in small blocks like map, grep, sort, and
> ) short evals.
>
> I usually leave out the trailing semicolon when the closing brace
> is on the same line, as I would with the trailing comma in lists.
For blocks which have no trailing semi themselves, like sub{}, if{} and
BEGIN{}, I omit the final semi inside if and only if the block contains
only one statement and the entire block fits on one line. For blocks
which return a value, like do{}, eval{} and map{}, I tend to omit the
final semi inside on the grounds that there's one on the end of the
statement outside.
Ben
------------------------------
Date: Tue, 28 Feb 2012 20:08:46 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4d263c$0$1388$4fafbaef@reader2.news.tin.it>
On 2/28/2012 15:51, Shmuel (Seymour J.) Metz wrote:
> In<agdt19-6r1.ln1@anubis.morrow.me.uk>, on 02/27/2012
> at 10:42 PM, Ben Morrow<ben@morrow.me.uk> said:
>
>> You're both wrong :). The parser insists on a semicolon to
>> terminate every statement, but the lexer inserts a semicolon
>> before the } at the end of a block and before the end of
>> every file.
>
> That's an implementation issue; the lexer is part of the
> implimentation.
You're right, but Larry Wall recommended putting the extra semicolon in
multi-statement blocks (in Programming Perl), so maybe he doesn't see
semicolons as separators. But you're right, nonetheless.
Kiuhnm
------------------------------
Date: Tue, 28 Feb 2012 14:38:55 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: given...when
Message-Id: <4f4d2d4f$18$fuzhry+tra$mr2ice@news.patriot.net>
In <4f4d263c$0$1388$4fafbaef@reader2.news.tin.it>, on 02/28/2012
at 08:08 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:
>You're right, but Larry Wall recommended putting the extra semicolon
>in multi-statement blocks (in Programming Perl), so maybe he doesn't
>see semicolons as separators.
Another poster gave what, IMHO, was a sound reason for the practice;
if you add a line you need a separating semicolon, but you don't want,
e.g., diff, to treat the original line as changed. Of course, you
could add a semicolon on a separate line, but that would generally be
poor style.
--
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: Tue, 28 Feb 2012 23:19:49 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4d5303$0$1384$4fafbaef@reader2.news.tin.it>
On 2/28/2012 20:38, Shmuel (Seymour J.) Metz wrote:
> In<4f4d263c$0$1388$4fafbaef@reader2.news.tin.it>, on 02/28/2012
> at 08:08 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> You're right, but Larry Wall recommended putting the extra semicolon
>> in multi-statement blocks (in Programming Perl), so maybe he doesn't
>> see semicolons as separators.
>
> Another poster gave what, IMHO, was a sound reason for the practice;
> if you add a line you need a separating semicolon, but you don't want,
> e.g., diff, to treat the original line as changed. Of course, you
> could add a semicolon on a separate line, but that would generally be
> poor style.
I understand, but why not using a smarter tool?
Kiuhnm
------------------------------
Date: Tue, 28 Feb 2012 23:06:12 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: given...when
Message-Id: <jijml3$786$1@reader1.panix.com>
In article <4f4d5303$0$1384$4fafbaef@reader2.news.tin.it>,
Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>On 2/28/2012 20:38, Shmuel (Seymour J.) Metz wrote:
>> In<4f4d263c$0$1388$4fafbaef@reader2.news.tin.it>, on 02/28/2012
>> at 08:08 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>>
>>> You're right, but Larry Wall recommended putting the extra
>>> semicolon in multi-statement blocks (in Programming Perl), so
>>> maybe he doesn't see semicolons as separators.
>>
>> Another poster gave what, IMHO, was a sound reason for the
>> practice; if you add a line you need a separating semicolon, but
>> you don't want, e.g., diff, to treat the original line as
>> changed. Of course, you could add a semicolon on a separate line,
>> but that would generally be poor style.
>
>I understand, but why not using a smarter tool?
The source-control tools I've used so far have been line based.
Specifically, when comparing revisions, they show lines. Certainly
UNIXy tools like diff are usually line-based. This is not to say that
anything else is impossible -- for example, Beyond Compare is a nice
diff tool that shows differences at the character level.
At my $ORKPLACE, our source-control tool is Perforce, and I have no
choice in that and no influence over changing it.
When evaluating tools, other factors may be more important than the
ability to show character-level diffs.
And the existing code base for Perl that I've seen uses semicolons as
statement terminators when in multi-line blocks.
--
Tim McDaniel, tmcd@panix.com
------------------------------
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 3625
***************************************
