why do these snippets have different behavior?

The following two versions don't have the same effect:

# 2-LINE VERSION; this way works as expected
my $v;
$v = "hello" if 0;

# 1-LINE VERSION; this way does not work as expected (imho)
my $v = "hello" if 0;

Example Program:

for my $i (1 .. 3) {
my $v = "hello" if 0;
print "v somehow defined: '$v', i = '$i'\n" if defined $v;
$v = "bye";
}

Sample Output:

v somehow defined: 'bye', i = '2'
v somehow defined: 'bye', i = '3'


When the 2-line snippet is used instead, the program produces no output, as
I was expecting.

It's as if not only the assignment (i.e. '= "hello"') part of the line is
subject to the conditional clause (false in this case), but also the
declaration (i.e. 'my') part of the line, too. Hence, the variable is not
re-declared each iteration, but retains its previous value. But if that
were truly the case, then it seems to me Perl should complain when $v is
assigned to "bye" since the variable was never declared (I have both
'strict' and 'warnings' on) which it doesn't. Although I suppose the
interpreter can't evaluate the conditional clause until runtime (even though
in this case the condition is static); maybe that's why?

Anyone else bothered by this behavior? This seems like a nasty feature.
Took me quite awhile before I realized some of my for-loop iterations were
interfering with each other...

Thanks,
Chris

Re: why do these snippets have different behavior?

On Sat, 22 Sep 2007 07:31:18 -0400, "Chris M."
wrote:

>The following two versions don't have the same effect:
>
># 2-LINE VERSION; this way works as expected
>my $v;
>$v = "hello" if 0;
>
># 1-LINE VERSION; this way does not work as expected (imho)
>my $v = "hello" if 0;

The one-line version is documented to have undefined results; see
"Statement Modifiers" in perldoc perlsyn. ( I wish they would put some
mention of this in the documetation for my as well.)
--
Eric Amick
Columbia, MD

Re: why do these snippets have different behavior?

Thanks, Eric. I'm sure I read that doc page a dozen times and it just never
clicked. "Here be dragons", indeed.

--Chris

"Eric Amick" wrote in message
news:dk5af31nj72sn35aupgfsha5jaua5cojh4@4ax.com...
> On Sat, 22 Sep 2007 07:31:18 -0400, "Chris M."
> wrote:
>
>>The following two versions don't have the same effect:
>>
>># 2-LINE VERSION; this way works as expected
>>my $v;
>>$v = "hello" if 0;
>>
>># 1-LINE VERSION; this way does not work as expected (imho)
>>my $v = "hello" if 0;
>
> The one-line version is documented to have undefined results; see
> "Statement Modifiers" in perldoc perlsyn. ( I wish they would put some
> mention of this in the documetation for my as well.)
> --
> Eric Amick
> Columbia, MD

Re: why do these snippets have different behavior?

On Sep 22, 7:31 am, "Chris M." wrote:
> The following two versions don't have the same effect:
>
> # 2-LINE VERSION; this way works as expected
> my $v;
> $v = "hello" if 0;
>
> # 1-LINE VERSION; this way does not work as expected (imho)
> my $v = "hello" if 0;
>
> Example Program:
>
> for my $i (1 .. 3) {
> my $v = "hello" if 0;
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
> $v = "bye";
>
> }
>
> Sample Output:
>
> v somehow defined: 'bye', i = '2'
> v somehow defined: 'bye', i = '3'
>
> When the 2-line snippet is used instead, the program produces no output, as
> I was expecting.
>
> It's as if not only the assignment (i.e. '= "hello"') part of the line is
> subject to the conditional clause (false in this case), but also the
> declaration (i.e. 'my') part of the line, too. Hence, the variable is not
> re-declared each iteration, but retains its previous value. But if that
> were truly the case, then it seems to me Perl should complain when $v is
> assigned to "bye" since the variable was never declared (I have both
> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
> interpreter can't evaluate the conditional clause until runtime (even though
> in this case the condition is static); maybe that's why?
>
> Anyone else bothered by this behavior? This seems like a nasty feature.
> Took me quite awhile before I realized some of my for-loop iterations were
> interfering with each other...
>
> Thanks,
> Chris

Curious - what is the benefit of putting the if at the end of the
line?

print "v somehow defined: '$v', i = '$i'\n" if defined $v;

versus

if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}

Bill H

Re: why do these snippets have different behavior?

On 2007-09-22, Bill H wrote:
> On Sep 22, 7:31 am, "Chris M." wrote:
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>>
>> Example Program:
>>
>> for my $i (1 .. 3) {
>> my $v = "hello" if 0;
>> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>> $v = "bye";
>>
>> }
>>
>> Sample Output:
>>
>> v somehow defined: 'bye', i = '2'
>> v somehow defined: 'bye', i = '3'
>>
>> When the 2-line snippet is used instead, the program produces no output, as
>> I was expecting.
>>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too. Hence, the variable is not
>> re-declared each iteration, but retains its previous value. But if that
>> were truly the case, then it seems to me Perl should complain when $v is
>> assigned to "bye" since the variable was never declared (I have both
>> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
>> interpreter can't evaluate the conditional clause until runtime (even though
>> in this case the condition is static); maybe that's why?
>>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>> Took me quite awhile before I realized some of my for-loop iterations were
>> interfering with each other...
>>
>> Thanks,
>> Chris
>
> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> Bill H
>

Seems to me the only benefit is a programmer with a mean spirit can use
the first form to make it harder for his fellow programmers to catch.
("Why don't I put the conditional clause at the end of the line where my
teammate Bill, whom I despise, is likely to miss it. Hopefully it will
cause him to introduce a bug in the code and get him fired.")

:-)

--

Re: why do these snippets have different behavior?

Quoth "Chris M." :
> The following two versions don't have the same effect:
>
> # 2-LINE VERSION; this way works as expected
> my $v;
> $v = "hello" if 0;
>
> # 1-LINE VERSION; this way does not work as expected (imho)
> my $v = "hello" if 0;

This has been a known, though undocumented, way of implementing an
equivalent to C's 'static' variables for a long time. The official
position from the perldocs is that the behaviour is undefined. 5.10 will
have 'state' variables, which give explicit and documented access to
equivalent behaviour.

> When the 2-line snippet is used instead, the program produces no output, as
> I was expecting.

The second statement is of course completely irrelevant, and is in fact
optimized away:

~% perl -MO=Deparse -e'my $x; $x = 2 if 0;'
my $x;
'???';
-e syntax OK
~%

('???'; from Deparse means 'there used to be a statement here, but it
got optimized away so I don't know what it said').

> It's as if not only the assignment (i.e. '= "hello"') part of the line is
> subject to the conditional clause (false in this case), but also the
> declaration (i.e. 'my') part of the line, too.

This is not quite what happens. 'my' has both run-time and compile-time
effects: at compile time, it causes a new variable to be declared; this
happens anyway. At runtime, it causes that variable to be reinitialized;
this part was accidentally made subject to the 'if 0'. Strictly
speaking, it's a bug in perl. But some clever people found out about it
and started depending on it, so it probably can't be fixed for a while
yet; hence the 'undefined' in the perldocs. As a rule, statements of the
form

my ... if ...;

or similar should be avoided.

> Hence, the variable is not re-declared each iteration, but retains its
> previous value. But if that were truly the case, then it seems to me
> Perl should complain when $v is assigned to "bye" since the variable
> was never declared (I have both 'strict' and 'warnings' on) which it
> doesn't. Although I suppose the interpreter can't evaluate the
> conditional clause until runtime (even though in this case the
> condition is static); maybe that's why?

Yes. The declaration happens at compile-time, so is unaffected by the
conditional. If the condition is known at compile-time, the whole
runtime effect of 'my' is optimized away, and Deparse gets so confused
it emits code that doesn't compile:

~% perl -MO=Deparse -Mstrict -e'my $x if 0; print $x'
use strict 'refs';
'???';
print $x;
-e syntax OK

> Anyone else bothered by this behavior? This seems like a nasty feature.

5.10 will warn, since the desired behaviour now has a proper syntax:

~% perl-current -we'my $x if 0;'
Deprecated use of my() in false conditional at -e line 1.
~%

> Took me quite awhile before I realized some of my for-loop iterations were
> interfering with each other...

What did you hope to achieve with that syntax anyway? Or did you simply
not realize you were attempting to make a 'my' conditional?

Ben

Re: why do these snippets have different behavior?

Bill H wrote:
> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
The benefit can be in better look only. I use both syntax, case to case
basis. Please compare this:

print "abc";
print "def";
print "HUH" unless defined $huh;
print "ghi";

print "abc";
print "def";
unless(defined $huh) {print "HUH";}
print "ghi";

In this case the primary job is to print something and only one case is
conditional. And in first example I spared 3 characters compared to second
example :-)

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: why do these snippets have different behavior?

On 23 Sep, 00:14, Ben Morrow wrote:

> 5.10 will warn,

> Deprecated use of my() in false conditional

About $EXPLETIVE time!

Re: why do these snippets have different behavior?

"Bill H" wrote in message
news:1190485710.111722.6330@y42g2000hsy.googlegroups.com...
> On Sep 22, 7:31 am, "Chris M." wrote:
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>>
>> Example Program:
>>
>> for my $i (1 .. 3) {
>> my $v = "hello" if 0;
>> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>> $v = "bye";
>>
>> }
>>
>> Sample Output:
>>
>> v somehow defined: 'bye', i = '2'
>> v somehow defined: 'bye', i = '3'
>>
>> When the 2-line snippet is used instead, the program produces no output,
>> as
>> I was expecting.
>>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too. Hence, the variable is
>> not
>> re-declared each iteration, but retains its previous value. But if that
>> were truly the case, then it seems to me Perl should complain when $v is
>> assigned to "bye" since the variable was never declared (I have both
>> 'strict' and 'warnings' on) which it doesn't. Although I suppose the
>> interpreter can't evaluate the conditional clause until runtime (even
>> though
>> in this case the condition is static); maybe that's why?
>>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>> Took me quite awhile before I realized some of my for-loop iterations
>> were
>> interfering with each other...
>>
>> Thanks,
>> Chris
>
> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> Bill H

I guess I would feel obligated to split the 'if' clause across 3 lines to
maintain coding style consistency,
which seems like a pain for such a small clause. :)

if (defined $v) {
print "v somehow defined: '$v', i = '$i'\n";
}

Whereas the end-of-line conditional check seems to lend itself nicely to a
1-line coding style.

And the off-chance that you do trip up one of your fellow programmers is
simply one more reason to use it... :)

Chris

Re: why do these snippets have different behavior?

On Sep 22, 10:26 pm, "Petr Vileta" wrote:
> Bill H wrote:
> > Curious - what is the benefit of putting the if at the end of the
> > line?
>
> > print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> > versus
>
> > if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> The benefit can be in better look only. I use both syntax, case to case
> basis. Please compare this:
>
> print "abc";
> print "def";
> print "HUH" unless defined $huh;
> print "ghi";
>
> print "abc";
> print "def";
> unless(defined $huh) {print "HUH";}
> print "ghi";
>
> In this case the primary job is to print something and only one case is
> conditional. And in first example I spared 3 characters compared to second
> example :-)
>
> --
>
> Petr Vileta, Czech republic
> (My server rejects all messages from Yahoo and Hotmail. Send me your mail
> from another non-spammer site please.)

It would seem if you start with the "if" it would parse faster than if
you end with it. Since, from what I read, perl compiles your code when
you run it, it would seem to be easier on the compiler to know ahead
of time that the following lines are conditional, instead of compiling
the line and then finding out it is conditional. For example:

if (2 == 3){print "Never print this line\n";}

would never get compiled (I would assume), but

print "Never print this line\n" if 2 == 3;

would get compiled and then thrown away when it reached the if
statement. I know this is non-sense code but it illustrates an extreme
example.

If I'm wrong, let me know.

Bill H

Re: why do these snippets have different behavior?

_
Chris M. (please_no_more@spam.net) wrote on VCXXXV September MCMXCIII in
:
^^ The following two versions don't have the same effect:
^^
^^ # 2-LINE VERSION; this way works as expected
^^ my $v;
^^ $v = "hello" if 0;
^^
^^ # 1-LINE VERSION; this way does not work as expected (imho)
^^ my $v = "hello" if 0;
^^
^^ Example Program:
^^
^^ for my $i (1 .. 3) {
^^ my $v = "hello" if 0;
^^ print "v somehow defined: '$v', i = '$i'\n" if defined $v;
^^ $v = "bye";
^^ }
^^
^^ Sample Output:
^^
^^ v somehow defined: 'bye', i = '2'
^^ v somehow defined: 'bye', i = '3'
^^
^^
^^ When the 2-line snippet is used instead, the program produces no output, as
^^ I was expecting.
^^
^^ It's as if not only the assignment (i.e. '= "hello"') part of the line is
^^ subject to the conditional clause (false in this case), but also the
^^ declaration (i.e. 'my') part of the line, too. Hence, the variable is not
^^ re-declared each iteration, but retains its previous value. But if that
^^ were truly the case, then it seems to me Perl should complain when $v is
^^ assigned to "bye" since the variable was never declared (I have both
^^ 'strict' and 'warnings' on) which it doesn't. Although I suppose the
^^ interpreter can't evaluate the conditional clause until runtime (even though
^^ in this case the condition is static); maybe that's why?

"my" has two effects: one at compile time (telling the compiler you're going
to use a variable with such-and-such a name), and one at runtime: it sets
the value of said variable ('undef', unless assigned to).

Considering that the run time effect doesn't happen (due to the 'if 0' part),
and that Perl will reuse the variable (you would have gotten a different
result if you entered the block by recursion instead of a loop), you're
getting what you observed.

^^ Anyone else bothered by this behavior? This seems like a nasty feature.

It's a feature that was used to create "state" variables; variable that
won't be initialized each time a loop has entered. Before calling it a
nasty feature, ask yourself 'why do I write my $v = "hello" if 0' in the
first place? What did you think it should have done instead?

^^ Took me quite awhile before I realized some of my for-loop iterations were
^^ interfering with each other...

Anyway, in perl 5.10, 'my $v = "hello" if 0' will trigger a warning.
And 5.10 will have not only have local(), our(), and my(), but also state(),
to declare state variables.

It will probably not do what you did with 'my $v = "hello" if 0', but
that's because I don't know why you wrote it in the first place.



Abigail
--
A perl rose: perl -e '@}>-`-,-`-%-'

Re: why do these snippets have different behavior?

_
Bill H (bill@ts1000.us) wrote on VCXXXV September MCMXCIII in
:
::
:: Curious - what is the benefit of putting the if at the end of the
:: line?

Why does it have to have a benefit?

:: print "v somehow defined: '$v', i = '$i'\n" if defined $v;
::
:: versus
::
:: if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}


What's the benefit of putting the print inside a different scope?



Abigail
--
:;$:=~s:
-:;another Perl Hacker
:;chop
$:;$:=~y
:;::d;print+Just.
$:;

Re: why do these snippets have different behavior?

"Ben Morrow" wrote in message
news:98kgs4-e97.ln1@osiris.mauzo.dyndns.org...
>
> Quoth "Chris M." :
>> The following two versions don't have the same effect:
>>
>> # 2-LINE VERSION; this way works as expected
>> my $v;
>> $v = "hello" if 0;
>>
>> # 1-LINE VERSION; this way does not work as expected (imho)
>> my $v = "hello" if 0;
>
> This has been a known, though undocumented, way of implementing an
> equivalent to C's 'static' variables for a long time. The official
> position from the perldocs is that the behaviour is undefined. 5.10 will
> have 'state' variables, which give explicit and documented access to
> equivalent behaviour.
>
>> When the 2-line snippet is used instead, the program produces no output,
>> as
>> I was expecting.
>
> The second statement is of course completely irrelevant, and is in fact
> optimized away:
>
> ~% perl -MO=Deparse -e'my $x; $x = 2 if 0;'
> my $x;
> '???';
> -e syntax OK
> ~%
>
> ('???'; from Deparse means 'there used to be a statement here, but it
> got optimized away so I don't know what it said').
>
>> It's as if not only the assignment (i.e. '= "hello"') part of the line is
>> subject to the conditional clause (false in this case), but also the
>> declaration (i.e. 'my') part of the line, too.
>
> This is not quite what happens. 'my' has both run-time and compile-time
> effects: at compile time, it causes a new variable to be declared; this
> happens anyway. At runtime, it causes that variable to be reinitialized;
> this part was accidentally made subject to the 'if 0'. Strictly
> speaking, it's a bug in perl. But some clever people found out about it
> and started depending on it, so it probably can't be fixed for a while
> yet; hence the 'undefined' in the perldocs. As a rule, statements of the
> form
>
> my ... if ...;
>
> or similar should be avoided.
>
>> Hence, the variable is not re-declared each iteration, but retains its
>> previous value. But if that were truly the case, then it seems to me
>> Perl should complain when $v is assigned to "bye" since the variable
>> was never declared (I have both 'strict' and 'warnings' on) which it
>> doesn't. Although I suppose the interpreter can't evaluate the
>> conditional clause until runtime (even though in this case the
>> condition is static); maybe that's why?
>
> Yes. The declaration happens at compile-time, so is unaffected by the
> conditional. If the condition is known at compile-time, the whole
> runtime effect of 'my' is optimized away, and Deparse gets so confused
> it emits code that doesn't compile:
>
> ~% perl -MO=Deparse -Mstrict -e'my $x if 0; print $x'
> use strict 'refs';
> '???';
> print $x;
> -e syntax OK
>
>> Anyone else bothered by this behavior? This seems like a nasty feature.
>
> 5.10 will warn, since the desired behaviour now has a proper syntax:
>
> ~% perl-current -we'my $x if 0;'
> Deprecated use of my() in false conditional at -e line 1.
> ~%
>
>> Took me quite awhile before I realized some of my for-loop iterations
>> were
>> interfering with each other...
>
> What did you hope to achieve with that syntax anyway? Or did you simply
> not realize you were attempting to make a 'my' conditional?
>
> Ben

Thanks for all the info. I had hoped that I was doing the same thing as the
2-line version: initializing a variable whose value would be undef by
default or some valid value if a condition were met. A more realistic
context I had recently fallen into the habit of using it in:

my $val = $hash_ref->{some_key} if exists $hash_ref->{some_key};

I used to code this as:

my $val = (exists $hash_ref->{some_key} ? $hash_ref->{some_key} : undef);

But as my hashes tend to be multiple levels deep, this led to long lines
that were sometimes awkward to split. The post-conditional line seemed much
more natural to split when needed:

my $val =
$hash_ref->{sub_hash1}{sub_hash2}{sub_hash3}{sub_hash4}{sub_ hash5}{some_key}
if exists
$hash_ref->{sub_hash1}{sub_hash2}{sub_hash3}{sub_hash4}{sub_ hash5}{some_key};

Hence my for-loop headaches...

Lesson learned.

--Chris

Re: why do these snippets have different behavior?

Quoth Bill H :
>
> It would seem if you start with the "if" it would parse faster than if
> you end with it. Since, from what I read, perl compiles your code when
> you run it, it would seem to be easier on the compiler to know ahead
> of time that the following lines are conditional, instead of compiling
> the line and then finding out it is conditional. For example:
>
> if (2 == 3){print "Never print this line\n";}
>
> would never get compiled (I would assume), but
>
> print "Never print this line\n" if 2 == 3;
>
> would get compiled and then thrown away when it reached the if
> statement. I know this is non-sense code but it illustrates an extreme
> example.
>
> If I'm wrong, let me know.

You are wrong. Not only are you completely wrong in detail (the two
compile to almost exactly the same code, the only difference being that
the first has a new scope for the body of the if, and in both cases, the
whole lot is compiled and the dead branch dropped by the optimizer
later) but this is a completely stupid direction to approach the problem
from. The only sensible question is which is more readable.

Ben

Re: why do these snippets have different behavior?

Bill H wrote:


> Curious - what is the benefit of putting the if at the end of the
> line?
>
> print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> versus
>
> if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}


It lets the programmer choose to emphasize the condition
(as in the 2nd above) or to emphasize the action (1st above).


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: why do these snippets have different behavior?

On Sep 23, 1:59 pm, Ben Morrow wrote:
> Quoth Bill H :
>
>
>
>
>
>
>
> > It would seem if you start with the "if" it would parse faster than if
> > you end with it. Since, from what I read, perl compiles your code when
> > you run it, it would seem to be easier on the compiler to know ahead
> > of time that the following lines are conditional, instead of compiling
> > the line and then finding out it is conditional. For example:
>
> > if (2 == 3){print "Never print this line\n";}
>
> > would never get compiled (I would assume), but
>
> > print "Never print this line\n" if 2 == 3;
>
> > would get compiled and then thrown away when it reached the if
> > statement. I know this is non-sense code but it illustrates an extreme
> > example.
>
> > If I'm wrong, let me know.
>
> You are wrong. Not only are you completely wrong in detail (the two
> compile to almost exactly the same code, the only difference being that
> the first has a new scope for the body of the if, and in both cases, the
> whole lot is compiled and the dead branch dropped by the optimizer
> later) but this is a completely stupid direction to approach the problem
> from. The only sensible question is which is more readable.
>
> Ben- Hide quoted text -
>
> - Show quoted text -

Ben

I'm glad I am wrong. I am glad that I am completely wrong.

In your tirad you mention that it is dropped by the optimizer. Maybe a
better question from me would have been, how can you write code that
is compiled and optimized faster?

On a side note, why do people get bent out of shape if you ask a
question? How can anyone ever learn if they don't ask?

Bill H

Re: why do these snippets have different behavior?

On Sep 23, 5:35 pm, Tad McClellan wrote:
> Bill H wrote:
> > Curious - what is the benefit of putting the if at the end of the
> > line?
>
> > print "v somehow defined: '$v', i = '$i'\n" if defined $v;
>
> > versus
>
> > if (defined $v){print "v somehow defined: '$v', i = '$i'\n";}
>
> It lets the programmer choose to emphasize the condition
> (as in the 2nd above) or to emphasize the action (1st above).
>
> --
> Tad McClellan
> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

That makes sense. Thanks Tad

Re: why do these snippets have different behavior?

Bill H wrote:


> It would seem if you start with the "if" it would parse faster than if
> you end with it. Since, from what I read, perl compiles your code when
^^^^
> you run it,


Where did you read that?

From perlrun.pod:

After locating your program, Perl compiles the entire program to an
internal form. If there are any compilation errors, execution of the
program is not attempted.
...
If the program is syntactically correct, it is executed.


The entire program is compiled *before* it is run.

So "which came first in the source" does not affect the
speed of parsing.


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: why do these snippets have different behavior?

Quoth Bill H :
> On Sep 23, 1:59 pm, Ben Morrow wrote:
> > Quoth Bill H :
> >
> > > It would seem if you start with the "if" it would parse faster than if
> > > you end with it.

> >
> > > If I'm wrong, let me know.
> >
> > You are wrong. Not only are you completely wrong in detail (the two
> > compile to almost exactly the same code, the only difference being that
> > the first has a new scope for the body of the if, and in both cases, the
> > whole lot is compiled and the dead branch dropped by the optimizer
> > later) but this is a completely stupid direction to approach the problem
> > from. The only sensible question is which is more readable.
>
> I'm glad I am wrong. I am glad that I am completely wrong.

Good.... :)

> In your tirad you mention that it is dropped by the optimizer. Maybe a
> better question from me would have been, how can you write code that
> is compiled and optimized faster?

No, you've missed my point completely. (I was worried I shouldn't have
put in the technical details.) Except under exceptional circumstances,
it is *simply not worth worrying* about the time it takes to compile
your code, and even when that time is significant, there are more
effective ways to go about reducing it (mod_perl, Autoloader, ...) than
being picky about style.

When it comes to matters of style, the *only* important question is
'which style is more comprehensible?'. The reason Perl has its postfix
logical operators is so you can write things like

next if /^#/;

which is a single 'sentence' and much easier to grasp in one go than

if ($_ =~ /^#/) {
next LINE;
}

The 'and' and 'or' operators exist for much the same reason:

open ... or die ...;

is much easier to read than either

die ... unless open ...;

or

unless (open ...) {
die ...;
}

One of the reasons writing C hurts my head is the need for so much

if (!(fd = open(...))) {
error(...);
}

stuff, and writing it as

fd = open(...);

if (!fd) {
error(...);
}

makes what could have been one idea into at least three, not to mention
completely breaking the flow of the code. It ends up reading like a
legal document.

See also perldoc perlstyle, of course.

> On a side note, why do people get bent out of shape if you ask a
> question? How can anyone ever learn if they don't ask?

On a side note, why do people get offended when they get a slightly curt
response to a rather silly question? How do they expect to learn if
they're more interested in being offended than listening to the answers?

*removes tongue from cheek*

Ben