Me personally, or the generally accepted way? My untested, "I hate answering these kinds of questions" way:

my $packname = 'Some::Module';
$packname =~ s!::!/!g;
$packname .= '.pm';
my $path = grep { -e "$_/$packname" } @INC or
    die "Can't find $packname in \@INC";

my $moduletext = '';
{
    local (*INPUT, $/);
    foreach my $file ($0, $path) {
        open( INPUT, $file ) or die "Can't open $file: $!";
        $moduletext .= <INPUT>;
    }
}

# almost ruined the joke here
require File::Temp;
my ($temphandle, $tempfile) = File::Temp::tempfile();
print *$temphandle $moduletext;
exec $moduletext;
[download]

Update: Yes, I'm finding the module, reading it, appending it to the current program, writing the whole thing to disk, and calling exec on it. I didn't say it was the *best* solution, only the most flippant that came to mind. (Especially since it has a potential infinite loop. :)

Pardon me, but...

What the HELL is that?

UPDATE: OK, now I know what it is. But, frankly, if someone gave that answer in an interview, I'd send them home ... after first trying to recruit them for my pet open source projects. I don't want somebody quite that contrary on a paying job, you see....

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Also what you should ask depends on context. Personally I avoid asking "Perl trivia". I would prefer to take a good programmer and teach them Perl than to try taking a Perl expert and teaching them good programming. (Getting someone who doesn't need teaching is, of course, preferable.) Given that I prefer to ask questions on strategies, algorithms, see them write some code I can go over for style, etc.

Well, I only used the &foo syntax for clarity of expression: "&foo" is the one and only name of the function "foo", while foo() could refer to an operator. When teaching or explaining about function calls I think it reasonable to use the ampersand. In real code, of course, I avoid ampersands whenever possible.

But to answer your question: I'd probably smile broadly and hire the candidate on the spot. If there was no hurry, I would first indulge in a thoroughly enjoyable argument over how attempts to improve readability can break things by accident. (Contrary to popular folklore, &func is not synonymous with func(@_); the former shares a single @_ array, while the latter makes a temp copy that disappears when func returns. Don't feel bad if you didn't know that; I actually caught TheDamian in the same mistake at TPC5.)

It's certainly true that a good programmer is a good programmer no matter his background. But background can take time to overcome, and some habits are difficult to unlearn. A really good programmer must grok his tools, above all his language. I was hired in my current job to mostly code Python (ack! spit!); I thought for sure I'd have no problem with it, but it's taken a few months to get get to the point where coding in Python isn't like translating English to Spanish word for word. (Which, incidentally, sucks.)

UPDATE: Fixed usage of the word "latter", per tilly's kind correction.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Don't feel bad if you didn't know that; I actually caught TheDamian in the same mistake at TPC5.

Well, it's certainly true: chip did indeed catch me out at TPC5. And in front of 400-500 people!

Though in fairness, my mistake occurred in SelfGOL: quite possibly the most complex 1000 bytes of Perl ever written.

But it wasn'tbecause I was unaware of the @_-sharing nature of &foo. In fact, the code in question deliberately abused that feature. I messed up because I (carelessly) relied on the behaviour once to often within the same block.

Nevertheless, I was very grateful to chip. His correction encoraged me to make SelfGOL even more diabolical. As indeed has this thread.

>;-)

I actually did know that, as is evidenced by the fact that I knew without looking at documentation that the right correction to what you wrote is s/latter/former/. :-)

(ie &foo shares @_, foo(@_) does not.)

Those who didn't know this should check out perlsub, or if you don't want to think carefully about consequences, the excellent summary at (tye)Re: A question of style. (Hrm, glancing at it a current version of perlsub gets it right twice, but the comment in the code sample is misleading.)