[33125] in Perl-Users-Digest
Perl-Users Digest, Issue: 4401 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 27 14:09:21 2015
Date: Fri, 27 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, 27 Mar 2015 Volume: 11 Number: 4401
Today's topics:
Re: An error on page 142 of The Camel Book. <hjp-usenet3@hjp.at>
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. <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. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 26 Mar 2015 23:15:20 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <slrnmh917o.48t.hjp-usenet3@hrunkner.hjp.at>
On 2015-03-24 19:24, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> [...]
>> I have occasionally written loops where there is exactly one exit point
>> and it is somewhere in the middle.
>
> "I have occasionally left my house by sitting down in front of the
> tele"?
Please don't play dumb. There are exactly 2 possible meanings of "exit
point" here and one of them is obviously completely useless in this
context. I don't believe for 1 second that you seriously think I meant
that. You are weird, but not stupid.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 26 Mar 2015 22:26:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87zj6z9yz7.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-03-24 19:24, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> [...]
>>> I have occasionally written loops where there is exactly one exit point
>>> and it is somewhere in the middle.
>>
>> "I have occasionally left my house by sitting down in front of the
>> tele"?
>
> Please don't play dumb.
I'm not playing dumb (as you're certainly very much aware): By the time
people came up with the 'should only have one exit point' rule, they
were referring to the actual _exit point_ of a construct, ie, the point
where execution continues afterwards, as I've demonstrated by quoting a
relevant text. This made sense at that time because there was no uniform
convention about this (I've posted some code illustrating this. Another
moderately famous paper, 'Structured Programming with Go To Statements'
use 'multi-exit' with exactly the same meaning).
Some time later, this "should have only one exit point" catchphrase was
re-purposed to mean something completely different, namely, "there
should be only one location in the implementation of a control-flow
construct which can cause it to exit", blissfully ignoring the fact that
something as simple as
if ? then S1 else S2
necessarily violates this construction as the implementation has to jump
over one of the branches which ought to count as a second exit point
when "all animals were actually created equal".
A loop like the one used on the example I quoted a couple of times,
$/ = \10;
while (<>) {
print("$_\n");
last if $. == 10;
}
perfectly satisfies Dijkstra's requirement of being usable as building
block in a sequence despite code which can cause it to exit appears in
two different locations.
[...]
> You are weird, but not stupid.
I sorely tempted to consider this the only real content of your posting.
------------------------------
Date: Thu, 26 Mar 2015 22:41:23 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87vbhn9yb0.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> Another moderately famous paper, 'Structured Programming with Go To
> Statements' use 'multi-exit' with exactly the same meaning
That's on page 18 of the PDF available here
http://web.archive.org/web/20130731202547/http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
in a section discussing replacement for 'unrestricted' gotos proposed by
various people, the actual quote is
Language features allowing multiple exits have been proposed by G. V. Bochmann [7],
and independently by Shigo et al. [86].
[...]
they express such semantics in terms of statements that say
"exit to (label)".
------------------------------
Date: Fri, 27 Mar 2015 15:56:10 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mf3r0k$4es$1@dont-email.me>
On 26.03.15 23:26, Rainer Weikusat wrote:
> Some time later,
I doubt that two papers from Europe were considered
the first and last word on control structure of programs.
But this doubt doesn't add clear definitions either,
thus preserving all possible outcomes of ambiguity in speech.
> something as simple as
>
> if ? then S1 else S2
>
> necessarily violates this construction
("if implicitly taken to imply ...")
All this bickering won't remove the fact that a jump necessarily
has two ends(*), that it may be expressed in source, which
is translated into something executable, which is then executed.
No actual loop will ever happen without a jump "back". So,
there are likely two, uhm, exits-or-not. Some target languages
have GOTO only with test. Should this test then be refelected
in source language, as a second condition when jumping back
to the beginning of a loop, depending on the target language?
> A loop like the one used on the example I quoted a couple of times,
>
> $/ = \10;
> while (<>) {
> print("$_\n");
> last if $. == 10;
> }
>
> perfectly satisfies Dijkstra's requirement of being usable as building
> block in a sequence despite code which can cause it to exit appears in
> two different locations.
There still is an argument for having an additional kind
of loop that doesn't only happen to be usable as a building
block in the quoted sense.
Instead, when there is a way to actually write some source
text and know from its syntax that this source text invariably
is a building block, then any time-consuming inference when
convincing yourself that it is a building block will no longer
be needed.
__
(*) formalists' ends would include those of jumping "up and down",
I guess, i.e. L: goto L, which I think speaks for itself.
------------------------------
Date: Fri, 27 Mar 2015 09:05:01 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <5515557d$1$fuzhry+tra$mr2ice@news.patriot.net>
In <87vbhn9yb0.fsf@doppelsaurus.mobileactivedefense.com>, on
03/26/2015
at 10:41 PM, Rainer Weikusat <rweikusat@mobileactivedefense.com>
said:
>http://web.archive.org/web/20130731202547/http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
Thanks for the link; now I don't have to resort to my dead tree. You
wouldn't happen to have a URL for Bohm & Jacopini, would you?
BTW, is the whole URL necessary or will
<http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf> work?
That is, is your URL a referal or a file in a wayback machine?
--
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, 27 Mar 2015 16:31:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87oanecsg7.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 26.03.15 23:26, Rainer Weikusat wrote:
>
>> Some time later,
>
> I doubt that two papers from Europe were considered
> the first and last word on control structure of programs.
> But this doubt doesn't add clear definitions either,
> thus preserving all possible outcomes of ambiguity in speech.
One of the two papers was written by an American and I quoted them as
example of 'common usage' wrt the term 'exit point' at (and by) the very
people who invented the 'should have only one exit point' rule (AFAIK,
this was either Dijkstra or Hoare who provided the actual flow charts)
...
>> something as simple as
>>
>> if ? then S1 else S2
>>
>> necessarily violates this construction
>
> ("if implicitly taken to imply ...")
>
> All this bickering won't remove the fact that a jump necessarily
> has two ends(*), that it may be expressed in source, which
> is translated into something executable, which is then executed.
.... if nothing ... the if - else construct is semantically equivalent
to
if !? then goto else:
S1
goto out:
else:
S2
out:
hence, it obviously sports two exit points when 'exit point' is supposed
to refer to code causing the construct to be left. That's a simple
fact and all this "bickering" can't change it: This idea of 'exit point'
is inconsistent with the very constructs proposed as a replacement for
'unrestricted gotos'.
[...]
>> A loop like the one used on the example I quoted a couple of times,
>>
>> $/ = \10;
>> while (<>) {
>> print("$_\n");
>> last if $. == 10;
>> }
>>
>> perfectly satisfies Dijkstra's requirement of being usable as building
>> block in a sequence despite code which can cause it to exit appears in
>> two different locations.
>
> There still is an argument for having an additional kind
> of loop that doesn't only happen to be usable as a building
> block in the quoted sense.
I can imagine such an argument but the one I do imagine is different
from the (misapplied) 'one exit point' rule usually used to justify
backwards logic like
while ($. < 10 && ($_ = <>))
(I'm calling this 'backwards' because the first half-test has been
designed to be harmless until the exit condition becomes true at the end
of an iteration despite it's checked at the beginning of one).
I also don't see much of a difference between
while (!$done) {
# some statements here
if (something()) {
$done = 1
} else {
# some more statements here
}
}
and
ups:
while (!$done) {
# ...
if (something()) {
$done = 1;
goto ups;
}
# ...
}
except that the former hides the strange control flow to a certain
degree. Presumably, such code can be restructured to avoid the explicit
jump altogether and that's a better idea than using if - else to emulate
it because "the g-word" must be avoided because .... well, just because
...
BTW, at least one programming language I know (and regularly use) has a
'basic loop' defined as
loop
-- do something
-- do somthing else
end loop
ie, the only way to exit it is by using explicit flow control.
------------------------------
Date: Fri, 27 Mar 2015 18:23:19 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mf43kh$9o3$1@dont-email.me>
On 27.03.15 17:31, Rainer Weikusat wrote:
> if !? then goto else:
> S1
> goto out:
> else:
> S2
> out:
>
> hence, it obviously sports two exit points when 'exit point' is supposed
> to refer to code causing the construct to be left.
Two "exit points" is precisely reflected in the design of the
syntax for this if/else. Mutatis mutandis in case there
is "elsif", or no "else"; There still can be "return" and
"goto Elsewhere" at one of the Sk. So, a typical if/else may be
as compliant with "enter here", "exit there" as the programmer
wishes it to be.
In this view, a corresponding if/else has 0, 1, or more than
2 places in source that a reader needs to consider when studying
control flow. "It's either this branch, or the other."
With loops, the syntactical consideration becomes:
"It's either here, or just about anywhere in the loop."
The "just about anywhere" part is what I wish to avoid.
Like Dijkstra and Hoare have addressed unbridled flow,
I want just a little more of that when a problem lends
itself to such a solution. Problems like those typically
solved by using "map", without "goto" in map's block.
>> There still is an argument for having an additional kind
>> of loop that doesn't only happen to be usable as a building
>> block in the quoted sense.
>
> I can imagine such an argument but the one I do imagine is different
> from the (misapplied) 'one exit point' rule usually used to justify
> backwards logic like
>
> while ($. < 10 && ($_ = <>))
[More about cases to which the "simplified" kind of loop
simply does not apply. (Not so well.) One rule of thumb
may say that the iterated steps could also be performed
in parallel.]
> BTW, at least one programming language I know (and regularly use) has a
> 'basic loop' defined as
>
> loop
> -- do something
> -- do somthing else
> end loop
>
> ie, the only way to exit it is by using explicit flow control.
Can you make your program exit from two places in the loop?
Is there syntax for that? Can the flow be to places other
than immediately after the loop?
------------------------------
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 4401
***************************************
