Perl `defined' and `undef' subroutine scope
Asked Answered
M

1

6

Please take a look at the following code:

use strict;
use warnings;


print "subroutine is defined\n" if defined &myf;
myf();

sub myf
{
        print "called myf\n";
}

undef &myf;
#myf();
print "now subroutine is defined\n" if defined &myf;

The output is

subroutine is defined
called myf

The first print statement can print, does that mean the interpreter (or compiler?) looks further and sees the subroutine definition? If so, why it doesn't see the undef &myf; as the second print statement?

Thanks

Marlenamarlene answered 20/9, 2016 at 10:52 Comment(1)
Because undef is code to run at runtime, but sub is a definition and happens at compile time.Kowtow
L
10

That doesn't have to do with scope, but with compile time and run time. Here's a simplified explanation.

The Perl interpreter will scan your code initially, and follow any use statements or BEGIN blocks. At that point, it sees all the subs, and notes them down in their respective packages. So now you have a &::myf in your symbol table.

When compile time has reached the end of the program, it will switch into run time.

At that point, it actually runs the code. Your first print statement is executed if &myf is defined. We know it is, because it got set at compile time. Perl then calls that function. All is well. Now you undef that entry in the symbol table. That occurs at run time, too.

After that, defined &myf returns false, so it doesn't print.

You even have the second call to myf() there in the code, but commented out. If you remove the comment, it will complain about Undefined subroutine &main::myf called. That's a good hint at what happened.

So in fact it doesn't look forward or backward in the code. It is already finished scanning the code at that time.


The different stages are explained in perlmod.

Note that there are not a lot of use cases for actually undefing a function. I don't see why you would remove it, unless you wanted to clean up your namespace manually.

Larine answered 20/9, 2016 at 10:58 Comment(7)
Great answer, but it doesn't explain why I can't write a statement myf; (or even main::myf;) before the subroutine is defined.Phinney
@Borodin: because at compile time the compiller does not know that myf or main::myf barewords are subroutine (turn off use strict and you get: Bareword "myf" not allowed while "strict subs" in use. After subroutine is defined you have a &::myf in your symbol table and you can write barewords myf or main::myf after definition. To ensure perl that you want to call subroutine just put parentheses after bareword: myf()Complicity
That was not part of the question @Phinney ;)Larine
@simbabque: No it wasn't. But on the surface it seems to contradict the idea that the compilation populates the symbol table so that the subroutine is available at run time. The ugly truth is that the compiler assumes that a simple myf is actually a string, despite use strict 'subs' being in place, and despite it producing a warning Useless use of a constant ("myf") in void context when treated as a string. All for the sake of backward-compatibility!Phinney
@Phinney I read about this the other day. It might have been in another question. Was someone maybe discussing to remove this finally?Larine
@simbabque: Nothing I've heard of. I might poke around if I have time.Phinney
It's not for backwards compatibility. Some people use paren-less calls to find typos and other errors at compile-time rather than when the call is executed.Bim

© 2022 - 2024 — McMap. All rights reserved.