The answer then was "impossible." Still the same now?

Yes.

Of course, now someone is going to come along with some deep mojo using B, PadWalker, some C code, and a system call to perl -d just to prove me wrong. Worse yet, they'll say "just use the Acme::Sub::Introspect::Argument::Names module; the get_names_of_passed_variables() function will work like a charm."

Seriously, what about calls with a literal like foo("bar") or calls with the return value of another sub like foo( bar() ) or calls with an element in a hash or an array? It doesn't seem like an easy problem.

I'm really curious about why you might want this. It would almost certainly be useless for anything but introspection for debugging or obfuscation and perl already has plenty of support for both of those without this capability.

Update: See. I just knew it. Devel::Caller, as PodMaster points out, will work as long as your calls don't get much harder than your example. It isn't a general solution. Some quick tests show it handles references poorly (it always returns '$bar' for foo($bar), foo(\$bar), foo(\\$bar), etc.) It doesn't seem to handle symbolic references at all. It also doesn't know about elements of an array or hash. For instance, foo($bar[0]) returns '@bar' and foo($bar{baz}) return '%bar'. Literals return undef.

-sauoq
"My two cents aren't worth a dime.";

There is also Devel::Caller which may be better suited to the task (came out a few months after the node you referenced).

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

foo(bar => 'baz');

sub foo {
   my %arg = @_;
   print "These were the 'vars' passed to me:\n";
   print "\t$_\n" for keys %arg;
}
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)