[33118] in Perl-Users-Digest
Perl-Users Digest, Issue: 4394 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 20 14:09:22 2015
Date: Fri, 20 Mar 2015 11:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 20 Mar 2015 Volume: 11 Number: 4394
Today's topics:
Re: An error on page 142 of The Camel Book. <kaz@kylheku.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <see.my.sig@for.my.address>
Re: An error on page 142 of The Camel Book. <see.my.sig@for.my.address>
Re: An error on page 142 of The Camel Book. <see.my.sig@for.my.address>
Re: An error on page 142 of The Camel Book. <see.my.sig@for.my.address>
Re: An error on page 142 of The Camel Book. <justin.1503@purestblue.com>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Re: An error on page 142 of The Camel Book. (Seymour J.)
Re: An error on page 142 of The Camel Book. <kaz@kylheku.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <kaz@kylheku.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Error Messages <edgrsprj@ix.netcom.com>
Re: Error Messages <gamo@telecable.es>
Re: Error Messages <jurgenex@hotmail.com>
REGEX question <hslee911@yahoo.com>
Re: REGEX question <jurgenex@hotmail.com>
Re: REGEX question <news@todbe.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Mar 2015 22:45:38 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <20150319154256.285@kylheku.com>
On 2015-03-19, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> "$Bill" <news@todbe.com> writes:
>> On 3/18/2015 16:19, Rainer Weikusat wrote:
>>>
>>> IMHO, for (;;) counting loops are a bad idea in any language.
>>
>> I can't think of a single reason why.
>
> I'll start with the anecdotical part: When I began using C seriously,
> about 14 years ago, two constructs greatly puzzled me, namely, the
> postincrement operator and the for(;;) loop, as I couldn't understand in
> what circumstances they might ever be really needed. I've meanwhile
> found (rare) sensible use for the postmods but none for for(;;).
>
> Non-anecdotical:
>
> for (<ex1>; <ex2>; <ex3>) <block>
>
> is a messy construct because it groups three unrelated things into a
> single line. It's equivalent to
It's a tidy construct because it groups three perfectly related
things into a single line: initialization, guard and increment.
------------------------------
Date: Thu, 19 Mar 2015 23:16:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87619wo9xp.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2015-03-19, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> "$Bill" <news@todbe.com> writes:
>>> On 3/18/2015 16:19, Rainer Weikusat wrote:
>>>>
>>>> IMHO, for (;;) counting loops are a bad idea in any language.
>>>
>>> I can't think of a single reason why.
>>
>> I'll start with the anecdotical part: When I began using C seriously,
>> about 14 years ago, two constructs greatly puzzled me, namely, the
>> postincrement operator and the for(;;) loop, as I couldn't understand in
>> what circumstances they might ever be really needed. I've meanwhile
>> found (rare) sensible use for the postmods but none for for(;;).
>>
>> Non-anecdotical:
>>
>> for (<ex1>; <ex2>; <ex3>) <block>
>>
>> is a messy construct because it groups three unrelated things into a
>> single line. It's equivalent to
>
> It's a tidy construct because it groups three perfectly related
> things into a single line: initialization, guard and increment.
I don't see how they would be related as I've explained in some length
in my original text already: The semantics you assign to the three
expressions only exist because of your interpretation. The first
expression isn't 'the initialization expression' but the statement
immediately in front of the loop body: It's "clearly related" to the
loop in the same way you (or I) are "clearly related" to someone
queueing in front of me, ie, not at all for the general case. The second
expression actually has a function, namely, the loop will terminate once
it's value isn't true. The third again doesn't, it's just the 'statement
immediately before the end of the loop body. Considering this, this is a
perfectly valid for (;;) loop:
for (print("I'm about to loop\n"); print("Loop start\n"); print("Loop end\n")) {
last unless $i < 5;
++$i;
}
Granted, similar nonsense is possible with other looping constructs but
for (;;) is an extreme example because it gratuitiously pulls things
together because certain code happened to appear in some position in
1973.
That
for ($i = 0; $i < 10; $i++) {}
happens to be capable of expressing
$i = 0;
do {
.
.
.
} while (++$i < 10);
in a horizontally more extended way (and at the expense of partly
nonsensical semantics) is not desirable in its own right. A real
counting loop, like the one which had existed in BCPL, or 'no counting
loop' as we can already express that like in B had been a better choice
than this 'facility for executing statements in a location different
from the one they appear in'.
------------------------------
Date: Thu, 19 Mar 2015 20:16:08 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <r62dncqdSudoDZbInZ2dnUVZ572dnZ2d@giganews.com>
On 3/19/2015 7:41 AM, Shmuel (Seymour J.) Metz wrote:
> The example you gave can be written equally easily as a foreach with a
> range; IMHO that would be clearer.
Good idea, now that you mention it. The program I have in mind has
nested C-style for loops like so:
FIRST: for (my $i = 0 ; $i < ($count - 1) ; ++$i)
{
...
SECOND: for (my $j = $i + 1 ; $j < $count ; ++$j)
{
...
I should probably simplify that to:
FIRST: for my $i (0..$count-2)
{
...
SECOND: for my $j ($i+1..$count-1)
{
...
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Thu, 19 Mar 2015 20:44:58 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <PqadncSDKZAqCpbInZ2dnUVZ572dnZ2d@giganews.com>
On 3/19/2015 3:20 AM, G.B. wrote:
> On 19.03.15 07:38, Robbie Hatley wrote:
>> but
>> once you realize that in machine language, assembly language, and C,
>> indices are "offsets from starting location", then you'll realize
>> that the index of the starting (first) location is 0, second
>> location is 1, third location is 2, etc. That's just the difference
>> between the layman's way of ordinalizing and the computer scientist's
>> way of ordinalizing.
>
> Except that this is a strange way of looking at "offset"
> as a name naming according to what the word means:
> at 0, there is no offset at all, hence a "layman" will
> ask what (existing thing) on earth you are taking about.
>
> As usual, the answer is along "vacuous truth": an offset
> of 0 is a linguistic oddity that still is convenient and
> useful to include among offsets.
>
> Consider instructions, inspired by assembly language,
> addressing a "layman":
>
> "John, move that barrel away from the wall, by zero inches!"
>
> Does this make sense in the head of the person so instructed?
Depends on the numeracy of the layman. If hir took math and science
classes in school and excelled in them, then yes, hir probably
has a good working relationship with the number 0, which is,
after all, one of the five most important numbers in mathematics:
0, 1, e, pi, i.
(Btw, believe it or not, those 5 numbers are related by a single
simple equation: e^(pi*i) + 1 = 0 )
Otherwise, if the person is not math savvy, the idea of 0 as
a number to indicate "null, zilch, nada" would likely not occur
to hir.
Nor would the idea of negative numbers to indicate "going the opposite
direction". So, to tell a person with an IQ of 73 "move the stone block
-2.3 meters to the east, please" is unlikely to illicit the desired action.
But making the same request of a person with an IQ of 128 would probably
get the idea across.
Likewise, not everyone is going to "get" zero indexing.
But then, not everyone is going to be able to program in C anyway.
It's a dangerous language for those not familiar with the way
computers work "under the hood" (CPUs, memory, addresses,
instruction codes, etc). Very easy to shoot yourself in the foot
in C if you're not familiar with computers at a detailed level.
Perhaps Perl would be a better choice for folks with little or no
computer-science background who need to do some programming.
Less likely to crash the system that way.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Thu, 19 Mar 2015 21:21:58 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <7eqdnTg99Kb-PZbInZ2dnUVZ57ydnZ2d@giganews.com>
On 3/19/2015 3:10 AM, G.B. wrote:
> On 19.03.15 04:36, Robbie Hatley wrote:
> > ... Always the following expression is true:
> > scalar(@ARGV) == $#ARGV + 1
>
> This equality doesn't hold:
>
> perl -e '$[ = 42; printf "#: %d, eq? %d\n", $#ARGV, @ARGV == $#ARGV+1'
Hmmm. Ok. But then, you've "cheated" by redefining all arrays,
globally, as being 42-indexed instead of 0-indexed. So your
equality is false because it's the wrong equality to be testing,
not because the underlying concept is bad.
The concept still holds that "count == HighestUsedIndex - base + 1".
If base is 0, that's written "@array == $#array - 0 + 1)"
If base is 42, that's written "@array == $#array - 42 + 1)"
#! /usr/bin/perl
# ~/scripts/test/asdf.perl
use strict;
use warnings;
use v5.14;
no warnings "deprecated";
$[ = 42;
say "\$[ = ", $[ ;
say "scalar(\@ARGV) = ", scalar(@ARGV) ;
say "\$#ARGV - \$[ + 1 = ", $#ARGV - $[ + 1 ;
Try running that with various numbers of arguments:
asdf.perl
asdf.perl 'alpha'
asdf.perl 'alpha' 'bravo'
asdf.perl 'alpha' 'bravo' 'charlie'
But who the heck (besides Douglas Adams perhaps) would want to
use 42-based indexing for arrays, anyway? (And Douglas Adams
is dead, so you can't claim he put you up to it. ;-) )
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Thu, 19 Mar 2015 21:31:23 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <V-adnUVeD54FP5bInZ2dnUVZ57ydnZ2d@giganews.com>
On 3/19/2015 8:44 AM, jurgenex@hotmail.com wrote:
> Robbie Hatley <see.my.sig@for.my.address> wrote:
> > Always the following expression is true:
> > scalar(@ARGV) == $#ARGV + 1
>
> No, it is not. The correct equivalence is
> scalar(@ARGV) == $[ + $#ARGV + 1
>
> It just happens that almost always $[ is zero. And almost always is
> _not_ good enough when it comes to computers and programming.
Thanks, that's good thing to know, especially when dealing with legacy code.
(Though, the only legacy code I've had to deal with so far has been
badly-written (obfuscated, un-commented) C, not Perl.)
And it's also a good argument for putting the following at the top of all
Perl programs:
use strict;
use warnings;
That throws up red flags when someone has gone and done something really
naughty such as "$[ = 42;".
:::casts mischievous glance at G.B.:::
(And it probably also pays to grep for "no strict" and "no warnings" to
see where the last guy turned them off to get away with stuff.)
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Fri, 20 Mar 2015 08:58:23 +0000
From: Justin C <justin.1503@purestblue.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <f24ttb-6q8.ln1@zem.masonsmusic.co.uk>
On 2015-03-19, Robbie Hatley <see.my.sig@for.my.address> wrote:
[snip]
> our @array;
> for ( my $i = 1 ; $i <= 100 ; ++$i ) {push(@array,$i);}
[snip]
Please, for clarity and brevity, do that like this:
our @array = (1..100);
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 20 Mar 2015 11:02:09 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <megr5h$fo9$1@dont-email.me>
On 20.03.15 05:21, Robbie Hatley wrote:
> But who the heck (besides Douglas Adams perhaps) would want to
> use 42-based indexing for arrays, anyway?
Anyone who divides and conquers an array of length 84,
simplifying the algorithm halfway by starting at symbolic
index value $[ in either recursion ;-)
------------------------------
Date: Thu, 19 Mar 2015 20:31:27 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <550b6a5f$1$fuzhry+tra$mr2ice@news.patriot.net>
In <873851j7ex.fsf@doppelsaurus.mobileactivedefense.com>, on
03/19/2015
at 04:09 PM, Rainer Weikusat <rweikusat@mobileactivedefense.com>
said:
>I'll start with the anecdotical part: When I began using C
>seriously, about 14 years ago, two constructs greatly puzzled me,
>namely, the postincrement operator and the for(;;) loop, as I
>couldn't understand in what circumstances they might ever be
>really needed.
Postincrement was clearly inspired by the instruction sets of the
PDP-7 and PDP-11. for(;;) is a DO FOREVER loop, which is quite useful.
--
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: Fri, 20 Mar 2015 14:50:10 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <20150320072802.260@kylheku.com>
On 2015-03-19, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
><ex3>. While this sounds nice and general, it's really only applicable
> to counting loops of the kind other languages, eg, Pascal or BCPL,
> support directly:
>
> for i := 1 to 66 step 3
>
> This can be expressed in C as
>
> for (i = 1; i <= 66; i += 3)
>
> but that's really a lower-level construct because instead of telling the
> computer what is desired, it specifies how to accomplish it. And it
> suggests a false sense of generality because certain 'common problems'
> can only be shoe-horned into this syntax by using it in ways it wasn't
> meant to be used, eg,
It is a lower level construct because it is based on the imperative
notion of iteration.
Iteration begins with some variables in initial state. A statement body is
evaluated subject to a guard condition over some or all of those variables, and
at the same time mutates those variables. The loop terminates when the guard
condition fails.
The for(;;) construct in C adds some "light weight organization" which reflects
this.
The organization can be used to write loops more clearly than something
completely undisciplined, and is not restricted to just walking over
a range of numbers.
for (fsm.init(); !fsm.goal_state(); fsm.step()) {
fsm.feed(input.get_next());
}
> Often, 'real loops' aren't that simple, eg they may use six or seven
> variables, some of which 'start out' with the proper values (eg, because
> they were passed as arguments) while others may need to be initialized
> and yet others can just be used starting with the default
> value.
*All* loops, no matter how messy, can be expressed as initialization, the
conditional execution of a body with an increment phase:x.
Say we have a C-like language, but with multiple-value function returns
and assignments.
We can then express a general loop: a vector of variables, all initialized;
a guard condition evaluate over all the variables; and the next value
of each variable calculated as a function of all the variables,
then simultaneously assigned to the entire vector of variables.
for ( (x0, x1, x2, ...) = (init0(), init1(), ...) ;
guard(x0, x1, x2, ...) ;
(x0, x1, x2, ...) = (next0(x0, x1, x2 ....),
next1(x0, x1, x2 ....)
....) )
{ /* empty */ }
Anything that can be calculated with any loop over these x0, x1, ...
can fit into this structure.
This structure, in turn, can be turned into tail recursion, which
avoids mutating variables:
func(x0, x1, x2, ...)
{
if (guard(x0, x1, x2, ...)
return func(next0(x0, x1, ...),
next1(x0, x1, ...),
...);
return (x0, x1, x2, ...)
}
We feed the initial values in, and obtain the final values.
The tail call optimization turns it into a loop, whereby the passing
of arguments to the recursive func call turns into assignments of
new values to x0, x1 ...
> Extremely long lines become unreadable quickly, hence, cramming
> six or seven initialiations into <ex1> is not a good idea.
for (x = 1, y = 2, z = 3, .... ;
bloop(x, y, z) != blorch(z, w);
x = flub(z, y), z = bork(y, x), ... )
{ /* whatever */ }
> compound expression is also difficult to modify because text editors can
> be used to shuffle lines of text around easily but not parts of lines.
So, program in assembler! Every instruction is clearly on a line by itself.
If you don't like the order of
add r0, r1, r2
mov r2, LOC
just put the vi cursor on the first line and go "ddp" on it's ass!
------------------------------
Date: Fri, 20 Mar 2015 15:10:13 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <874mpfd7sa.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2015-03-19, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>><ex3>. While this sounds nice and general, it's really only applicable
>> to counting loops of the kind other languages, eg, Pascal or BCPL,
>> support directly:
>>
>> for i := 1 to 66 step 3
>>
>> This can be expressed in C as
>>
>> for (i = 1; i <= 66; i += 3)
>>
>> but that's really a lower-level construct because instead of telling the
>> computer what is desired, it specifies how to accomplish it. And it
>> suggests a false sense of generality because certain 'common problems'
>> can only be shoe-horned into this syntax by using it in ways it wasn't
>> meant to be used, eg,
>
> It is a lower level construct because it is based on the imperative
> notion of iteration.
It's a lower-level construct because provides 'statement teleportation'
of arbitrary statements.
> Iteration begins with some variables in initial state. A statement body is
> evaluated subject to a guard condition over some or all of those variables, and
> at the same time mutates those variables. The loop terminates when the guard
> condition fails.
>
> The for(;;) construct in C adds some "light weight organization" which reflects
> this.
The for(;;) construct reflects that fact that someone (at some time in
the past) considered "last statement before the loop" and "last
statement in the loop body" 'somehow special' and because of that, chose
to move the 'last statement in front of the loop' into the loop head so
that it's no longer in front of it and the last statement of the loop
body into the loop head so that it no longer the last statement of the
loop body.
> The organization can be used to write loops more clearly than something
> completely undisciplined, and is not restricted to just walking over
> a range of numbers.
>
> for (fsm.init(); !fsm.goal_state(); fsm.step()) {
> fsm.feed(input.get_next());
> }
Considering that neither "last statement in front of the loop" nor "last
statement of the loop body" have any inherent meaning, this construct
can obviously be used to perturb any sequential algorithm to some
degree.
------------------------------
Date: Fri, 20 Mar 2015 17:27:22 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mehhnp$900$1@dont-email.me>
On 20.03.15 16:10, Rainer Weikusat wrote:
> The for(;;) construct reflects that fact that someone (at some time in
> the past) considered "last statement before the loop" and "last
> statement in the loop body" 'somehow special' and because of that, chose
> to move the 'last statement in front of the loop' into the loop head so
> that it's no longer in front of it and the last statement of the loop
> body into the loop head so that it no longer the last statement of the
> loop body.
If it is possible to express every iterative construct
as the triple of that state transition in "for(;;)"
(tricky, I guess, in some cases), is there any other way
of doing so in Perl?
I mean, in such a way that there can be no doubt as to
what statement belongs to initial state, condition, or
variation? That's assuming that programmers are
willing and able to agree that this is the intent of
constructs like "for(;;)".
Example:
sub z
{
my $k;
for ($k=0;
--$k;
++$k)
{
$k++;
}
return $k;
}
Ignoring purpose and result of the computation, how could I,
using syntax, establish $k == 0 as nothing but the loop's initial
state, without any doubt?
??? $k ???
while (... $k ...)
{
...
} continue {
... $k ...
}
Until the reader reaches "while", it seems unclear to me
that the preceding line expresses the initial state of $k.
The increment in the loop body may be fixed by moving
to the "varying" section of "for(;;)" or "while/continue"
through teleportation and then adding. But, again, I imagine
that sometimes the loop body is computing $k, so that
a "varing part" or "continue" block won't be that helpful.
------------------------------
Date: Fri, 20 Mar 2015 16:27:47 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87k2yb3a7w.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 3/19/2015 8:44 AM, jurgenex@hotmail.com wrote:
[...]
> (And it probably also pays to grep for "no strict" and "no warnings" to
> see where the last guy turned them off to get away with stuff.)
I never put "use strict; use warnings;" in code but not because this
means "I can get away with stuff" but because these are two useless lines
of code for anyone but a developer making changes. When working with/ on
something sufficiently complicated, I usually use a Makefile running
perl -cw -Mstrict
on any changed files upon typing 'make' (life's too short too waste it
with testing code that doesn't even compile cleanly).
http://perl.plover.com/yak/12views/samples/notes.html#sl-31
------------------------------
Date: Fri, 20 Mar 2015 16:57:51 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87d24338ts.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 20.03.15 16:10, Rainer Weikusat wrote:
>> The for(;;) construct reflects that fact that someone (at some time in
>> the past) considered "last statement before the loop" and "last
>> statement in the loop body" 'somehow special' and because of that, chose
>> to move the 'last statement in front of the loop' into the loop head so
>> that it's no longer in front of it and the last statement of the loop
>> body into the loop head so that it no longer the last statement of the
>> loop body.
>
> If it is possible to express every iterative construct
> as the triple of that state transition in "for(;;)"
> (tricky, I guess, in some cases), is there any other way
> of doing so in Perl?
There are no 'state transitions' in for (;;). The (pseudo-)Perl equivalent of
for (<ex0>; <ex1>; <ex2>) { <ex3>; }
is
<ex0>;
{
last unless <ex1>;
<ex3>;
<ex2>;
redo;
}
Any algorithm which can textually be expressed in this way can also be
put into the for-line, ie, for (;;) can always be used to express "Well,
I wrote a *= 2; ++a but I meant ++a; a *= 2!" (Am I not expressing
myself neatly?)
> I mean, in such a way that there can be no doubt as to
> what statement belongs to initial state, condition, or
> variation?
<sarcasm>
Oh, that's really easy: The code which gets executed before the loop is
entered is collectivly "code which gets executed before the loop is
entered". The 'condition' is usually cleverly obfuscated by putting it
in place of the condition and only a genius with uncanny understanding
would suspect the code in the body of the loop to be the loop body. I
mean, without inverting the logic, who could ever possibly follow its
course?
</>
------------------------------
Date: Fri, 20 Mar 2015 17:07:52 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <20150320100319.953@kylheku.com>
On 2015-03-20, G.B. <bauhaus@futureapps.invalid> wrote:
> On 20.03.15 16:10, Rainer Weikusat wrote:
>> The for(;;) construct reflects that fact that someone (at some time in
>> the past) considered "last statement before the loop" and "last
>> statement in the loop body" 'somehow special' and because of that, chose
>> to move the 'last statement in front of the loop' into the loop head so
>> that it's no longer in front of it and the last statement of the loop
>> body into the loop head so that it no longer the last statement of the
>> loop body.
>
> If it is possible to express every iterative construct
> as the triple of that state transition in "for(;;)"
> (tricky, I guess, in some cases), is there any other way
> of doing so in Perl?
Moreover, the iteration becomes more clearly revealed when we break it into its
initialization, guard and increment steps. If we then assign these to the
elements of the for loop's syntactic sugar, we will likely gain some measure of
clarity.
> I mean, in such a way that there can be no doubt as to
> what statement belongs to initial state, condition, or
> variation? That's assuming that programmers are
> willing and able to agree that this is the intent of
> constructs like "for(;;)".
>
> Example:
>
> sub z
> {
> my $k;
> for ($k=0;
> --$k;
> ++$k)
> {
> $k++;
> }
> return $k;
> }
This is an "abuse" of the for loop because a loop variable is incremented in
the body *and* in the portion of the syntax intended for increments.
The body of an ideal for should contain only imperative logic that does
not mess with the loop variables. Such as I/O:
for (i = 0; i < N; i++) /* the complete loop logic is here */
print(object[i]); /* just the side effect of output */
Once the body starts containing various hacks, like conditional breaks,
continues, or updates of loop variables, it deviates from the ideal form;
the expressions placed in the (;;) part start to lose those aspects of its
meaning which connect to the ideal structure.
------------------------------
Date: Fri, 20 Mar 2015 17:25:49 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <878uer37j6.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
[...]
> The body of an ideal for should contain only imperative logic that does
> not mess with the loop variables. Such as I/O:
>
> for (i = 0; i < N; i++) /* the complete loop logic is here */
> print(object[i]); /* just the side effect of output */
>
> Once the body starts containing various hacks, like conditional breaks,
> continues, or updates of loop variables, it deviates from the ideal
> form;
9.6 For statement
The for statement has the form
for (expression-1[opt]; expression-2[opt]; expression-3[opt]) statement
This statement is equivalent to
expression-1;
while ( expression-2 ) {
statement
expression-3 ;
}
Thus the first expression specifies initialization for the loop;
the second specifies a test, made before each iteration, such
that the loop is exited when the expression becomes 0; the third
expression typically specifies an incrementation which is
performed after each iteration.
http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
As implicitly communicated above, not even C is restricted to this ex
post factum invention of 'the ideal loop' (Exactly how I always write
them! What a lucky coincidence!) as it supplies both a proper[*] loop
with test at the beginning in form of
while (condition) statement;
and a proper loop with test at the end,
do statement; while (condition)
[*] 'proper' is here supposed to mean 'the syntax restricts itself to
what is necessary for the loop itself'.
Perl is more expressive in this respect as it supports
- loops with test at the beginning,
while (<condition) {}
for executing the block the condition is true and
until (<condition>) {}
for executing it until the condition becomes true.
- the same with test at the end
do { } while condition;
do { } until condition;
- loop which iterates over a list/ set
for (@list) {}
- bare blocks can be used in case where none of the above is a
good fit
It also supports for (;;) to humour people whose minds cling to that.
------------------------------
Date: Fri, 20 Mar 2015 18:46:16 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mehmbn$sci$1@dont-email.me>
On 20.03.15 17:57, Rainer Weikusat wrote:
> There are no 'state transitions' in for (;;).
(Is this a literal interpretation of "for (;;)"?)
> The (pseudo-)Perl equivalent of
>
> for (<ex0>; <ex1>; <ex2>) { <ex3>; }
>
> is
>
> <ex0>;
> {
> last unless <ex1>;
> <ex3>;
> <ex2>;
> redo;
> }
>
> Any algorithm which can textually be expressed in this way can also be
> put into the for-line,
But is it, or its opposite, advantageous to do?
Easy to do?
As an example, can I suggest that f below be transformed to
use for-form, one that is clear, ideal, preferred, canonical,
you name it?
sub f
{
my $k = shift || 0; # <ex0>
my $j = 0; # <ex0>
{
last unless $j <= $k; # <ex1>
do {}; # <ex3>
++$j, $k = f(--$k); # <ex2>
redo;
}
return $k;
}
------------------------------
Date: Fri, 20 Mar 2015 18:08:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <874mpf35kq.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 20.03.15 17:57, Rainer Weikusat wrote:
>
>> There are no 'state transitions' in for (;;).
>
> (Is this a literal interpretation of "for (;;)"?)
>
>> The (pseudo-)Perl equivalent of
>>
>> for (<ex0>; <ex1>; <ex2>) { <ex3>; }
>>
>> is
>>
>> <ex0>;
>> {
>> last unless <ex1>;
>> <ex3>;
>> <ex2>;
>> redo;
>> }
>>
>> Any algorithm which can textually be expressed in this way can also be
>> put into the for-line,
>
> But is it, or its opposite, advantageous to do?
>
> Easy to do?
>
> As an example, can I suggest that f below be transformed to
> use for-form, one that is clear, ideal, preferred, canonical,
> you name it?
>
> sub f
> {
> my $k = shift || 0; # <ex0>
> my $j = 0; # <ex0>
> {
> last unless $j <= $k; # <ex1>
> do {}; # <ex3>
> ++$j, $k = f(--$k); # <ex2>
> redo;
> }
> return $k;
> }
I'd write this as
sub f
{
my $k = shift;
my $j;
while ($j <= $k) {
++$j;
$k = f($k - 1);
}
}
That is, a loop which, while a certain condition holds, performs some
manipulations of 'the state' in its body. One could argue that
until ($j > $l) {
++$j;
$k = f($k - 1);
}
would be preferable because the test is simpler: In many cases, >=, <=
and ! are only used because the lack of a suitable looping construct
necessitates transforming the most straight-forward test expression.
NB: A bit theoretical. I didn't really use until loops (in Perl) so far,
I'm just considering to use them based on noticing that I have stopped
using if (!...) in favour of unless (...).
------------------------------
Date: Fri, 20 Mar 2015 03:18:10 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Error Messages
Message-Id: <BKOdnaGdbLEjSpbInZ2dnUU7-LudnZ2d@earthlink.com>
Error Messages Question
Is there a command that can be inserted at the start of a Perl
language program that will cause compilation error messages to be sent to a
text file instead of being displayed on the computer screen?
ActiveState Perl 5.10 is being used with Window XP, Vista, Windows 7,
and Windows 8.
The reason for continuing to use that older version is that commands
that are specific to modules associated with that version are being used in
a number of active Perl language programs. And at this time it would take
too long to convert them to a newer version of Perl. Instead, the Perl code
is gradually being translated to Fortran to improve calculation speeds.
When the Perl language programs are run from a Windows computer
screen any error messages disappear so quickly they cannot be seen. To
compensate for that I have developed a routine that makes it possible to run
the programs from a Windows DOS screen. Then the error messages remain on
the screen for as long as desired.
It would be my guess that there must be some command that can be
placed at the start of a Perl language program that will result in
compilation error messages to be sent to a text file (.txt) instead of to
the computer screen.
Or, perhaps that instruction can be included in the command that
starts the Perl program running.
Does anyone remember what that command or instruction might be for
that older version of Perl?
------------------------------
Date: Fri, 20 Mar 2015 10:14:31 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Error Messages
Message-Id: <megoe1$mri$1@speranza.aioe.org>
El 20/03/15 a las 09:18, E.D.G. escribió:
> Error Messages Question
>
> Is there a command that can be inserted at the start of a Perl
> language program that will cause compilation error messages to be sent
> to a text file instead of being displayed on the computer screen?
>
> ActiveState Perl 5.10 is being used with Window XP, Vista,
> Windows 7, and Windows 8.
>
> The reason for continuing to use that older version is that
> commands that are specific to modules associated with that version are
> being used in a number of active Perl language programs. And at this
> time it would take too long to convert them to a newer version of Perl.
> Instead, the Perl code is gradually being translated to Fortran to
> improve calculation speeds.
>
> When the Perl language programs are run from a Windows computer
> screen any error messages disappear so quickly they cannot be seen. To
> compensate for that I have developed a routine that makes it possible to
> run the programs from a Windows DOS screen. Then the error messages
> remain on the screen for as long as desired.
>
> It would be my guess that there must be some command that can be
> placed at the start of a Perl language program that will result in
> compilation error messages to be sent to a text file (.txt) instead of
> to the computer screen.
>
> Or, perhaps that instruction can be included in the command that
> starts the Perl program running.
>
> Does anyone remember what that command or instruction might be
> for that older version of Perl?
>
What you want is to redirect standard error to a file.
That must be covered in your Windows and DOS manuals.
That said, in Linux common shell is as simple as:
$ perl -e '$a = 1/0;' 2>error.log
$ cat error.log
Illegal division by zero at -e line 1.
(1 is standard output or STDOUT and 2 is standard error or STDERR)
HTH
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Fri, 20 Mar 2015 07:49:16 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Error Messages
Message-Id: <b4coga5mjlgvnoo14v7e54ehctipmparhu@4ax.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote:
>Error Messages Question
>
> Is there a command that can be inserted at the start of a Perl
>language program that will cause compilation error messages to be sent to a
>text file instead of being displayed on the computer screen?
No, that is technically impossible.
A program has to be compiled successfully before it can be started. Any
compilation error would prevent this start in the first place.
But what is wrong with simply redirecting the output of the compiler to
the desired text file? Why doesn't that work for you?
> When the Perl language programs are run from a Windows computer
>screen any error messages disappear so quickly they cannot be seen.
Why don't you just scroll back up? Or are you getting that many error
messages that they disappear from the screen buffer? If so then you may
want to increase the "Height" of that screen buffer.
>To
>compensate for that I have developed a routine that makes it possible to run
>the programs from a Windows DOS screen.
Well, that _is_ the standard way of running a Perl program. How else
would you do it or debug it?
>Then the error messages remain on
>the screen for as long as desired.
So, now you are saying the error messages are not disappearing quickly?
> Or, perhaps that instruction can be included in the command that
>starts the Perl program running.
>
> Does anyone remember what that command or instruction might be for
>that older version of Perl?
That has nothing to do with Perl but is a standard feature of any
command line shell, even including cmd.exe. It is called output
redirection.
jue
------------------------------
Date: Thu, 19 Mar 2015 14:05:10 -0700 (PDT)
From: James <hslee911@yahoo.com>
Subject: REGEX question
Message-Id: <0ae94d75-3ea2-45c4-8434-029c28670354@googlegroups.com>
Input line:
"<td>aa<td align=right>bb<td align=left width=50>cc<more"
my regex:
s/<td.*?>(.+?)<td.*?>(.+?)<td.*?>(.+?)</$1\t$2\t$3/;
Is there a short hand for (.*?) or (.+?) ?
Can this be simplified?
TIA
James
------------------------------
Date: Thu, 19 Mar 2015 14:14:54 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: REGEX question
Message-Id: <91fmga10qrub71dcpoo6ltdc6kr7s8gm2r@4ax.com>
James <hslee911@yahoo.com> wrote:
>Input line:
>
>"<td>aa<td align=right>bb<td align=left width=50>cc<more"
>
>my regex:
>
>s/<td.*?>(.+?)<td.*?>(.+?)<td.*?>(.+?)</$1\t$2\t$3/;
>
>Is there a short hand for (.*?) or (.+?) ?
>Can this be simplified?
Yep.
use HTML::Parser;
jue
------------------------------
Date: Thu, 19 Mar 2015 19:37:00 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: REGEX question
Message-Id: <550B87CC.5080008@todbe.com>
On 3/19/2015 14:05, James wrote:
> Input line:
>
> "<td>aa<td align=right>bb<td align=left width=50>cc<more"
>
> my regex:
>
> s/<td.*?>(.+?)<td.*?>(.+?)<td.*?>(.+?)</$1\t$2\t$3/;
>
> Is there a short hand for (.*?) or (.+?) ?
> Can this be simplified?
I don't know about simplified, but often I would druther use [^<]* or [^<]+ .
------------------------------
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 4394
***************************************
