[32724] in Perl-Users-Digest
Perl-Users Digest, Issue: 3988 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 12 21:09:29 2013
Date: Fri, 12 Jul 2013 18: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, 12 Jul 2013 Volume: 11 Number: 3988
Today's topics:
Re: [OT] scoping aka 'new holes in old shoes' <rweikusat@mssgmbh.com>
[OT] scoping <oneingray@gmail.com>
Re: [OT] scoping <hjp-usenet3@hjp.at>
Re: [OT] scoping <rweikusat@mssgmbh.com>
Re: [OT] scoping (Seymour J.)
Re: [OT] scoping <ben@morrow.me.uk>
Re: I'd like to try Perl... (Tim McDaniel)
Re: I'd like to try Perl... <ben@morrow.me.uk>
Re: I'd like to try Perl... (Tim McDaniel)
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <ben@morrow.me.uk>
Re: this should work <rvtol+usenet@xs4all.nl>
Re: this should work <source@netcom.com>
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work <source@netcom.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 12 Jul 2013 11:53:35 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] scoping aka 'new holes in old shoes'
Message-Id: <877ggw2gnk.fsf_-_@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
>> and IMHO, with a good reason: When people can't have multiple
>> disjunct sets of variables used by unrelated parts of the same
>> 'aggregate subroutine', they do what they should be doing instead,
>> namely, structure their code.
>
> I disagree. I deem the use of nested scopes as crucial to code
> structuring. Should the "roles" of the variables (whether
> input, output, or local) become apparent later, it'd be trivial
> to split the function, -- and that's likely to be done exactly
> along the scope boundaries previously coded in.
To quote my boss: Make it work now quickly and clean it up later
:-). Which means: Take some existing code which performs a
more-or-less related task, copy'n'paste it to some part of the
countryside where no trenches have been dug yet or the old ones worn
out over time, create a new nested scope lest all hell breaks lose
because any accidental interaction with the surrounings,
any details about them long lost in the land of ancient lore, will
surely lead to immediate disaster (nobody really knows if it will but
better not take any chances), create some new variables in order to
mark this as YOUR lamppost (and because reading to code which was just
copied would take too much time), change whatever looks as if it
absolutely needs to be changed (this - of course - excludes any
comments, after all, comments aren't executed so their content doesn't
matter and if there were none, some had to be written) and proudly
declare 'mission accomplished', wondering how the top of the desk
managed to look like the busy flight deck of a fleet carrier for a
passing moment.
The rest of the story will then exactly unfold as Georgie 'The Brain's
attempt to copy'n'pase a desert storm for enduring freedom (or the
equally 'patent' idea to invade Afghanistan for yet another time --- I
wonder if Karzai will make it out of the country before entering into
an uncomformtably close relationship with Naschdibullah's lantern):
For as long as nobody runs out of money for paying people in order to
get surreptitiously killed, the hazy vision that - tomorrow! - the
stuff will surely start to work (thereby proving that quantity turns
into quality when trying hard enough) can be maintained.
Somewhere, I read that the practical reaction to the so-called
'software crisis' was mostly renaming programmers to software
engineers and replacing ingenious with structured as preferred
adjective for describing the product (here supposed to mean 'what is
produced') and then continue business as usual. After all, the looks
had all changed, and better not meddle with those tried and trusted
methods (mainframe projects ending up cancelled in despair after
millions of $currrency were sunk into them PAY people for a long time
after all).
------------------------------
Date: Fri, 12 Jul 2013 07:50:02 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [OT] scoping
Message-Id: <874nc0w72t.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> It is about habits grown out of the perfectly accidental fact that a
> certain language allows variable declarations in inner scopes. Not
> all of them do ...
[...]
> ... and specifically, a certain language who was explicitly created
> to teach beginners about 'proper scoping' and 'cleanly designed
> code', namely, Pascal, doesn't
Somehow, my impression was that it /does/ allow for nested
variable scopes. However, I have only a passing experience with
the language.
> and IMHO, with a good reason: When people can't have multiple
> disjunct sets of variables used by unrelated parts of the same
> 'aggregate subroutine', they do what they should be doing instead,
> namely, structure their code.
I disagree. I deem the use of nested scopes as crucial to code
structuring. Should the "roles" of the variables (whether
input, output, or local) become apparent later, it'd be trivial
to split the function, -- and that's likely to be done exactly
along the scope boundaries previously coded in.
--
FSF associate member #7257
------------------------------
Date: Fri, 12 Jul 2013 14:58:43 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: [OT] scoping
Message-Id: <slrnktvvc3.erc.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-12 07:50, Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> > ... and specifically, a certain language who was explicitly created
> > to teach beginners about 'proper scoping' and 'cleanly designed
> > code', namely, Pascal, doesn't
Pascal was designed in the late 1960s, only about a decade after
FORTRAN and COBOL. I hope we have learned something in the more than
four decades since then.
> Somehow, my impression was that it /does/ allow for nested
> variable scopes.
Maybe ISO Pascal does now. But Pascal as originally designed by Wirth
didn't. All the variable declarations had to be at the beginning of the
program, procedure or function and the code had to be at the end (with
possibly more nested procedures or functions in between). Of course the
nested procedures and functions could have their own properly scoped
variables, so there were nested scopes, but only at the
procedure/function level, not at the block level. This had two negative
consequences: Variable declarations in the outer procedures were
separated widely (often hundreds or thousands of lines) from the place
where they were used and they were visible in all the inner procedures,
so it was easy to accidentally reuse a loop variable in an inner
procedure called from that loop. I think a large part of the motivation
for Knuth's WEB came from the rigid structure of Pascal which forced you
to put stuff which logically belonged together into different portions
of the program.
> However, I have only a passing experience with the language.
Likewise. And all that experience happened in the 1980s, so it's almost
as dated as my experience with BASIC (the line-numbers-and-goto kind of
BASIC).
> > and IMHO, with a good reason: When people can't have multiple
> > disjunct sets of variables used by unrelated parts of the same
> > 'aggregate subroutine', they do what they should be doing instead,
> > namely, structure their code.
>
> I disagree. I deem the use of nested scopes as crucial to code
> structuring. Should the "roles" of the variables (whether
> input, output, or local) become apparent later, it'd be trivial
> to split the function, -- and that's likely to be done exactly
> along the scope boundaries previously coded in.
>
Right. I split functions/methods quite frequently. Either if a function
becomes too long or if I notice that I need part of a function in a
different function. Nested scopes make this kind of refactoring a
no-brainer. And of course they make reading the code a lot simpler, too.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | 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: Fri, 12 Jul 2013 15:50:48 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] scoping
Message-Id: <87oba7vnlj.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2013-07-12 07:50, Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> > ... and specifically, a certain language who was explicitly created
>> > to teach beginners about 'proper scoping' and 'cleanly designed
>> > code', namely, Pascal, doesn't
>
> Pascal was designed in the late 1960s, only about a decade after
> FORTRAN and COBOL. I hope we have learned something in the more than
> four decades since then.
ALGOL 60 was (as the name may suggest) designed at the beginning of
the 1960s and it included the concept of nested lexical scopes with
attached variable sets, cf
http://www.masswerk.at/algol60/report.htm
This means your statement would be more appropriately worded as: Four
decades after someone suggested a different approach, we are as
unconvinced as ever that anything was deficient with the tradional way
of handling this.
[Pascal program structure description]
> This had two negative consequences: Variable declarations in the
> outer procedures were separated widely (often hundreds or thousands
> of lines) from the place where they were used
That's not a consequence of having to put variable definitions at the
beginning of a procedured but of including 'hundreds or thousands' of
lines of loosely related code in between and the simple solution to
this problem is "Don't do that".
> and they were visible in all the inner procedures, so it was easy to
> accidentally reuse a loop variable in an inner procedure called from
> that loop.
Again, the way to solve the problem that 'nobody can still find his
way through this mess' is to avoid creating it in the first place:
Don't separate 'declaration and use' of a variable by 'thousands of
lines of code', move these 'thousands of lines' into subroutines which
don't have to share state with some parent routine and pass the data
they need to them as arguments.
[...]
>> > and IMHO, with a good reason: When people can't have multiple
>> > disjunct sets of variables used by unrelated parts of the same
>> > 'aggregate subroutine', they do what they should be doing instead,
>> > namely, structure their code.
>>
>> I disagree. I deem the use of nested scopes as crucial to code
>> structuring. Should the "roles" of the variables (whether
>> input, output, or local) become apparent later, it'd be trivial
>> to split the function, -- and that's likely to be done exactly
>> along the scope boundaries previously coded in.
>
> Right. I split functions/methods quite frequently. Either if a function
> becomes too long or if I notice that I need part of a function in a
> different function. Nested scopes make this kind of refactoring a
> no-brainer.
The point is that this 'kind of refactoring' shouldn't ever be
necessary because the '15,000 lines of code and counting' 'subroutine'
shouldn't have been created to begin with: That's another of these
'outlandish new concepts' people have been ignoring for four decades
now ('stepwise refinement') because 'the old ways' don't need no
fixing especially since ...
> And of course they make reading the code a lot simpler, too.
... abstraction is evil because it hides details. It is claimed that
some of them wouldn't be significant at some higher level but
actually, higher level already sounds highly suspicious ...
------------------------------
Date: Fri, 12 Jul 2013 13:34:46 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: [OT] scoping
Message-Id: <51e03e36$1$fuzhry+tra$mr2ice@news.patriot.net>
In <87oba7vnlj.fsf@sapphire.mobileactivedefense.com>, on 07/12/2013
at 03:50 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>ALGOL 60 was (as the name may suggest) designed at the beginning of
>the 1960s
No and no; the name suggests that it became available in 1960, not
that it was designed in 1960, much less any other year in the early
1960's. In fact "Report on the Algorithmic Language ALGOL 60" was
published in May 1960. There were preparatory meeting in 1959 prior to
the January 1960 Conference that published the ALGOL 60 report. ALGOL
60 compilers were in production well before the publication of Revised
Report on the Algorithmic Language Algol 60; in fact, experience with
those compilers helped to motivate the revised report.
--
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, 12 Jul 2013 22:04:52 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <kk76ba-bv9.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Fri, 12 Jul 2013 15:50:48 +0100, Rainer Weikusat wrote:
>
> > Again, the way to solve the problem that 'nobody can still find his way
> > through this mess' is to avoid creating it in the first place: Don't
> > separate 'declaration and use' of a variable by 'thousands of lines of
> > code', move these 'thousands of lines' into subroutines which don't have
> > to share state with some parent routine and pass the data they need to
> > them as arguments.
>
> Although I agree that it is a bad idea, it is how Pascal was meant to be
> used. In the mean time, we learned this was not the greatest of ideas,
> and likewise, I think 'tight' scoping of variables is a very good idea.
Rainer has a point, buried somewhere in the bluster, in that if a sub
needs to be divided into two or more bare blocks in order to limit the
scope of variables those blocks should probably be diked out into
separate subs. I very rarely use bare blocks, and when I do it's usually
for their loop properties (so that next/last/redo will work) rather than
their scoping.
Ben
------------------------------
Date: Fri, 12 Jul 2013 02:04:04 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: I'd like to try Perl...
Message-Id: <krno6k$ln0$1@reader2.panix.com>
Catching up on the newsgroup.
In article <e11eaa-c5h2.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Hmm, glancing at that just confirms my opinion: mixing native Win32
>facilities with ported-from-Unix facilities with Cygwin facilities
>just leads to worlds of pain. Since, IME, native Win32 facilities
>cannot be avoided entirely, this makes using Cygwin an exercise in
>hacking around compatibility problems.
In my long experience with Cygwin, I use it for file processing (perl
and sed and pipes and such) and running some commands that it provides
(ssh, for example). I don't know what "Win32 facilities" might refer
to, but when it comes to files and using drive letters, Cygwin has
been perfectly usable.
From just the other replies I've seen, much of your other knowledge
is outdated or incomplete.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 12 Jul 2013 14:47:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: I'd like to try Perl...
Message-Id: <11e5ba-695.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> Catching up on the newsgroup.
>
> In article <e11eaa-c5h2.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >Hmm, glancing at that just confirms my opinion: mixing native Win32
> >facilities with ported-from-Unix facilities with Cygwin facilities
> >just leads to worlds of pain. Since, IME, native Win32 facilities
> >cannot be avoided entirely, this makes using Cygwin an exercise in
> >hacking around compatibility problems.
>
> In my long experience with Cygwin, I use it for file processing (perl
> and sed and pipes and such) and running some commands that it provides
> (ssh, for example). I don't know what "Win32 facilities" might refer
> to, but when it comes to files and using drive letters, Cygwin has
> been perfectly usable.
Programs which are not Cygwin programs, and don't understand Cygwin
paths.
> From just the other replies I've seen, much of your other knowledge
> is outdated or incomplete.
Very likely.
Ben
------------------------------
Date: Fri, 12 Jul 2013 15:57:06 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: I'd like to try Perl...
Message-Id: <krp90i$65u$1@reader2.panix.com>
In article <11e5ba-695.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> Catching up on the newsgroup.
>>
>> In article <e11eaa-c5h2.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >Hmm, glancing at that just confirms my opinion: mixing native Win32
>> >facilities with ported-from-Unix facilities with Cygwin facilities
>> >just leads to worlds of pain. Since, IME, native Win32 facilities
>> >cannot be avoided entirely, this makes using Cygwin an exercise in
>> >hacking around compatibility problems.
>>
>> In my long experience with Cygwin, I use it for file processing (perl
>> and sed and pipes and such) and running some commands that it provides
>> (ssh, for example). I don't know what "Win32 facilities" might refer
>> to, but when it comes to files and using drive letters, Cygwin has
>> been perfectly usable.
>
>Programs which are not Cygwin programs, and don't understand Cygwin
>paths.
In practice, I haven't had much need for them, other than
double-clicking applications which therefore don't interact with
Cgywin at all, or just typing them at the Cygwin shell. But on the
command line,
... $(cygpath -w /some/cygwin/path) ...
produces something along the lines of
... C:\some\cygwin\path ...
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 11 Jul 2013 23:17:12 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87li5coi6v.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> writes:
>> > On 2013-07-11, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> >>
>> >> because the 'my $tmp' is invariant code: It's effective result never
>> >> changes throughout the loop.
>> >
>> > This strikes me as premature optimization.
>>
>> 'Premature optimization' is a term which originally referred to the idea
>> of trying to write an 'optimal' machine-language programming 'from the
>> start', instead of concentrating on writing a working machine-language
>> program first and then - possibly - transform that into an
>> also-working but faster machine-language program and this in the
>> context of highly 'irregular' CISC-architecture as they were (still)
>> common in the 1970s where a lot of relatively 'bizarre' ways to
>> perform semantically identical operations in different ways actually
>> existed and it makes a hell lot of sense in this context.
>>
>> It was never meant to be a universal justification for "But I don't
>> want to think about that!" and certainly also not for "But I don't
>> want to change my habits!"
>
> This is not about habits:
It is about habits grown out of the perfectly accidental fact that a
certain language allows variable declarations in inner scopes. Not all
of them do ...
> anyone who's been here (or anywhere else
> programming is taught) for a while will know that getting beginners to
> understand the value of proper scoping is not easy. It's about
> cleanliness:
... and specifically, a certain language who was explicitly created to
teach beginners about 'proper scoping' and 'cleanly designed code',
namely, Pascal, doesn't and IMHO, with a good reason: When people
can't have multiple disjunct sets of variables used by unrelated parts
of the same 'aggregate subroutine', they do what they should be doing
instead, namely, structure their code.
------------------------------
Date: Fri, 12 Jul 2013 01:04:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: this should work
Message-Id: <spt3ba-i9r2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Charles DeRykus <derykus@gmail.com> writes:
>
> > But it (illogically) stays alive longer than is needed unless you
> > insert an additional, artificial scope as another poster showed:
>
> The 'logically' was supposed to refer to the fact that perl employs
> self-defense mechanisms against code of this type by NOT doing what
> the author requested: It keeps the variable alive despite this seems
> 'ill/im' (arbitrary suffix attached) to some people:
It explicitly does not keep the variable alive: it sets the PADSTALE
bit, which indicates that this variable is 'dead', and prevents string
evals and such from picking the variable up by mistake. It doesn't
deallocate the storage used for the variable, but that's just the same
level of optimisation as malloc uses when it doesn't reduce the brk just
because something has been freed.
All lexicals are actually allocated (but marked dead) at compile time,
and exist for the whole life of the program, along with all targets used
for intermediate temporaries. This is why it's possible to access
lexicals from BEGIN blocks. New copies are allocated when a sub
recurses, and deallocated when the recursion returns, but there is
always at least one copy of every lexical in existance.
> The computer has
> been programmed to work around this obsession with the
> 'micro-optimized lifecycle management' (And this is a euphemism. I'd
> wager a bet this this is practically just 'create a new variable
> whenever you need one because remembering what variables were created
> two lines ago would be SO cumbersome' [and 'plan in advance variables
> will be needed' an imposition beyond any physically tolerable by
> man]).
We are not writing assembler, where you have a limited number of
registers and their use needs to be planned carefully. A variable is
just a way of giving a value a name; giving things names is good, and
giving different things different names is also good. The whole point of
lexical variables is to avoid the problems that occur when uncontrolled
and implicit data leakage occurs between different parts of the program;
having Perl ensure that values we no longer need are properly disposed
of as soon as possible is just common sense.
(And, again, this is not about efficiency, either of CPU or memory. It's
about making the code comprehensible.)
> Do you think it was programmed to work around that because this is
> such a great idea? I don't. Especially since the computer can only
> work around the execution time penalty of this convention and not
> against the mess in the source code ("which of the 1,375 $i I
> encountered in the last 2000 lines of code is it this time?").
Um, it's the one in the 'my' statement just above your cursor. That's
the whole point of tight scoping: except for the various kinds of
globals, which should not be created lightly and do require planning,
the scope of a single variable should not exceed one screenful of code.
That means you can always see exactly which variable you are dealing
with, what has happened to it in the past, and what will happen to it in
the future.
If you are having to deal with code which has multiple variables with
the same name in nested scopes, some extending over hundreds of lines of
code, you have my sympathies. That is not a code style I am advocating.
I would recommend that at your earliest opportunity you go through it
and break it up into sensibly-sized sub: IME it doesn't usually take
very long, and enormously improves the comprehensibility of the code.
Ben
------------------------------
Date: Fri, 12 Jul 2013 15:44:38 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: this should work
Message-Id: <51e00846$0$15923$e4fe514c@news2.news.xs4all.nl>
On 11/07/2013 19:02, David Harmon wrote:
> Are you really proposing that the programmer should be expected to
> write:
>
> {
> my $tmpdir;
> foreach my $dir (qw/commands_pre commands_post/) {
> $tmpdir = "/tmp/$dir";
> print "$tmpdir\n"
> }
> }
I would expect her to write it as:
print "/tmp/$_\n"
for qw/ commands_pre commands_post /;
--
Ruud
------------------------------
Date: Fri, 12 Jul 2013 09:34:15 -0700
From: David Harmon <source@netcom.com>
Subject: Re: this should work
Message-Id: <e4adnQXPM5QprX3MnZ2dnUVZ_hGdnZ2d@earthlink.com>
On Thu, 11 Jul 2013 22:04:45 +0100 in comp.lang.perl.misc, Ben
Morrow <ben@morrow.me.uk> wrote,
>> Are you really proposing that the programmer should be expected to
>> write:
>>
>> {
>> my $tmpdir;
>> foreach my $dir (qw/commands_pre commands_post/) {
>> $tmpdir = "/tmp/$dir";
>> print "$tmpdir\n"
>> }
>> }
>
>This will, of course, be a good bit slower than with the my inside the
>loop. Blocks are quite expensive, because they're one-iteration loops,
>and that requires a bit of setup.
Sorry to hear that. To me the block is important, if I am going to
move the variable out of the loop at all, so that I don't have to
read further to see if that variable is going to be used later on.
I'm more used to C, where a block like that is pretty near zero
runtime cost.
------------------------------
Date: Fri, 12 Jul 2013 18:16:44 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87k3kvvgub.fsf@sapphire.mobileactivedefense.com>
David Harmon <source@netcom.com> writes:
> On Thu, 11 Jul 2013 22:04:45 +0100 in comp.lang.perl.misc, Ben
> Morrow <ben@morrow.me.uk> wrote,
>>> Are you really proposing that the programmer should be expected to
>>> write:
>>>
>>> {
>>> my $tmpdir;
>>> foreach my $dir (qw/commands_pre commands_post/) {
>>> $tmpdir = "/tmp/$dir";
>>> print "$tmpdir\n"
>>> }
>>> }
>>
>>This will, of course, be a good bit slower than with the my inside the
>>loop. Blocks are quite expensive, because they're one-iteration loops,
>>and that requires a bit of setup.
>
> Sorry to hear that.
When adding an additional block to the last out_of_loop example I
posted, it doesn't become any slower than it was without the block.
------------------------------
Date: Fri, 12 Jul 2013 15:53:46 -0700
From: David Harmon <source@netcom.com>
Subject: Re: this should work
Message-Id: <M9Odnd3rtvFmFX3MnZ2dnUVZ_oiXnZ2d@earthlink.com>
On Fri, 12 Jul 2013 15:44:38 +0200 in comp.lang.perl.misc, "Dr.Ruud"
<rvtol+usenet@xs4all.nl> wrote,
>On 11/07/2013 19:02, David Harmon wrote:
>
>> Are you really proposing that the programmer should be expected to
>> write:
>>
>> {
>> my $tmpdir;
>> foreach my $dir (qw/commands_pre commands_post/) {
>> $tmpdir = "/tmp/$dir";
>> print "$tmpdir\n"
>> }
>> }
>
>I would expect her to write it as:
>
> print "/tmp/$_\n"
> for qw/ commands_pre commands_post /;
I assume the OP's example is just a stripped-down fragment for
purposes of 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 3988
***************************************
