Is $_ special somehow?

[Steve]

I'm going through the O'reilly book and I learned about the next
operator. So this works, as it should:

-----------------------------------------
my @words = qw#hello kayak prong#;
for (@words)
{
next if /kayak/;
print "$_\n";
}
-----------------------------------------

However, if I write it as this, it doesn't work:
-----------------------------------------
my @words = qw#hello kayak prong#;
for my $word (@words)
{
next if /kayak/;
print "$word\n";
}

 

[Uri Guttman]

S> I'm going through the O'reilly book and I learned about the next
S> operator. So this works, as it should:

there are many o'reilly books on perl. which one are you reading?

S> -----------------------------------------
S> my @words = qw#hello kayak prong#;

# is a poor choice for a string delimiter. the best practice choices are
usually paired chars like () or {}. some styles like // especially when
passing args to a use command.

S> for (@words)
S> {
S> next if /kayak/;
S> print "$_\n";
S> }
S> -----------------------------------------

S> However, if I write it as this, it doesn't work:
S> -----------------------------------------
S> my @words = qw#hello kayak prong#;
S> for my $word (@words)
S> {
S> next if /kayak/;
S> print "$word\n";
S> }
S> -----------------------------------------

S> Why is this? I thought in this case, $_ and $word would contain the
S> same thing?

you don't say what is different or show output. this is a classic newbie
issue saying something doesn't work but not saying what you expected vs
what you see.

now i can see the issue and it is very simple. for will only alias its
list elements to $_ if you don't supply a loop variable. in the second
case you do so /kayak/ will match against $_ which isn't set (or has
some older value left over). this means you likely weren't using
warnings which would have told you that $_ was undef (assuming that for
the moment). that would have clued you in to noticing $_ was never being
set in the second loop. you could have also tested that by printing $_
in the second loop. that is a classic debugging technique. you think $_
would be set or the /kayak/ would match against it but that wasn't the
case. some simple prints of the right things would have told you
this. always check your assumptions with debugging prints when you are
not sure about something.

so this lesson was more than on your bug but how to debug your own code.

uri

 

[John Bokma]

you don't say what is different or show output. this is a classic newbie
issue saying something doesn't work but not saying what you expected vs
what you see.

He did: he expect the second snippet to work like the first. It doesn't
matter what the output is IMO, since it's clear what the mistake is in
the second example.

Please don't make beginners look stupid, thank you.

 

[Uri Guttman]

JB> He did: he expect the second snippet to work like the first. It doesn't
JB> matter what the output is IMO, since it's clear what the mistake is in
JB> the second example.

JB> Please don't make beginners look stupid, thank you.

i beg to differ. claiming the two outputs aren't the same isn't the same
as saying what is different about them. that info would always make it
easier to find the bug. and it is a good lesson on how to describe
bugs. the classic 'it doesn't work' is something you need to teach to
avoid.

uri

 

[Willem]

John Bokma wrote:
)
)> you don't say what is different or show output. this is a classic newbie
)> issue saying something doesn't work but not saying what you expected vs
)> what you see.
)
) He did: he expect the second snippet to work like the first. It doesn't
) matter what the output is IMO, since it's clear what the mistake is in
) the second example.

It is irrelevant that the mistake is clear.

The OP cannot know that it is clear, otherwise they would have known what
the mistake is in the first place. Therefore, they should have posted
all information that would be helpful to solving the problem, such as
exactly what the expected and actual outputs are, etcetera.

Being a beginner, they have just as much to learn about how to ask
questions effectively as about programming itself.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[sln]

John Bokma wrote:
)
)> you don't say what is different or show output. this is a classic newbie
)> issue saying something doesn't work but not saying what you expected vs
)> what you see.
)
) He did: he expect the second snippet to work like the first. It doesn't
) matter what the output is IMO, since it's clear what the mistake is in
) the second example.

It is irrelevant that the mistake is clear.

The OP cannot know that it is clear, otherwise they would have known what
the mistake is in the first place.

He said he was learning about the next operator. How is he learning about
that and doesen't know the for operator?
Furthermore, how does he know that $_ would contain anything, or what it
is in this context?

[snip]

Being a beginner, they have just as much to learn about how to ask
questions effectively as about programming itself.

But the questions is why did he put a variable between for and the list?
(he is just learning about "next")
And how does he know what this means:
"next if /kayak/;"

I think the question is fake.
Usually beginners would start with something traditional and laborous:

for (my $i = 0; $i < @words; $i++)
{
if ($words[$i] =~ /kayak/)
{
next;
}
# do something else
}

-sln

 

[John Bokma]

JB> He did: he expect the second snippet to work like the first. It doesn't
JB> matter what the output is IMO, since it's clear what the mistake is in
JB> the second example.

JB> Please don't make beginners look stupid, thank you.

i beg to differ. claiming the two outputs aren't the same isn't the same
as saying what is different about them. that info would always make it
easier to find the bug. and it is a good lesson on how to describe
bugs. the classic 'it doesn't work' is something you need to teach to
avoid.

On the latter I agree wholeheartedly with you. But to me the OP posted
sufficient information to provide a solution IMO. I think most people
here saw the solution before even reading what was wrong with it .

 

[John Bokma]

John Bokma wrote:
)
)> you don't say what is different or show output. this is a classic newbie
)> issue saying something doesn't work but not saying what you expected vs
)> what you see.
)
) He did: he expect the second snippet to work like the first. It doesn't
) matter what the output is IMO, since it's clear what the mistake is in
) the second example.

It is irrelevant that the mistake is clear.

To quote Uri: "I beg to differ". ;-)

 

[Willem]

John Bokma wrote:
)> i beg to differ. claiming the two outputs aren't the same isn't the same
)> as saying what is different about them. that info would always make it
)> easier to find the bug. and it is a good lesson on how to describe
)> bugs. the classic 'it doesn't work' is something you need to teach to
)> avoid.
)
) On the latter I agree wholeheartedly with you. But to me the OP posted
) sufficient information to provide a solution IMO. I think most people
) here saw the solution before even reading what was wrong with it .

Your 'but' is irrelevant. You don't seem to get the point.

For simple problems, a half-assed description is enough to spot the
problem. However, somebody who posts simple problems is also learning
*how to ask questions*. And giving half-assed descriptions is not a
good way to ask questions. Therefore, you should look beyond the simple
problem and see the opportunity to educate somebody on the efficiency
of question-asking.

I notice that crossthread, you posted 'i beg to differ' to my post where
I made roughly the same point. You also snipped my argumentation, and
gave no arguments of your own. That is not a good way to argue.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[John Bokma]

John Bokma wrote:
)> i beg to differ. claiming the two outputs aren't the same isn't the same
)> as saying what is different about them. that info would always make it
)> easier to find the bug. and it is a good lesson on how to describe
)> bugs. the classic 'it doesn't work' is something you need to teach to
)> avoid.
)
) On the latter I agree wholeheartedly with you. But to me the OP posted
) sufficient information to provide a solution IMO. I think most people
) here saw the solution before even reading what was wrong with it .

Your 'but' is irrelevant. You don't seem to get the point.

I do get "the point", we just disagree.

gave no arguments of your own. That is not a good way to argue.

Argueing only makes sense if at least one party is willing to learn,
hence pointless here.

 

[Justin C]

I'm going through the O'reilly book and I learned about the next
operator. So this works, as it should:

-----------------------------------------
my @words = qw#hello kayak prong#;
for (@words)
{
next if /kayak/;
print "$_\n";
}
-----------------------------------------

However, if I write it as this, it doesn't work:
-----------------------------------------
my @words = qw#hello kayak prong#;
for my $word (@words)
{
next if /kayak/;
print "$word\n";
}

next if ($word =~ /kayak/);

see perldoc perlvar for details on $_

Justin.