Sure, you can store perl code as a string in a file or a database. Here is an example of how to turn it into a sub.

$code = "print 'Hello World.'";  # This may have come for your DB
$sub = eval "sub { $code }"; # use eval and string interpolation to co
+nvert it into an anon. sub
$sub->(); # Execute the sub;

# To pass arguments to the sub, do this:
$sub->($a1, $a2); #etc

# You can capture the return value too
$ret = $sub->();
[download]

Update: I almost forgot to warn you: be very careful with who has access to the string version of the perl code. Obviously, if that data came from an untrusted source, they could destroy your system!

Dynamic code is also very hard to debug. I would recommend something like the following, to help you find out when/where it has errors.

$code = "print 'Hello World.'";
$sub = eval "sub { $code }";
unless ($sub) {
  # ack! it failed to eval
  # lets leave a note about the code, and the error
  # so we can debug this.
  die sprintf('CODE: %s\n\nERROR: %s\n\n', $code, $@);
}
[download]

If you want to name your subroutines, then just stick in a name at the right spot.

sub make_sub {
  my ( $sub_name, $code ) = @_ ;
  local $@;
  eval "sub $sub_name { $code }" ;
  die "make_sub $sub_name: $@\n" if $@;
}

make_sub( say_hello => 'print "Hello @_\n"' );
say_hello( 'World' );
__END__
Hello World
[download]

Note that this will throw wierd warnings if you try to create two subs with the same name. You can work around those....

...but chances are that you don't really need to use eval for whatever you're trying to do. You can probably get away with writing a module which contains all the functions you want to store in your database, and then just store the function names in the database instead. Have your program fetch the right name from the database, then then call it.

Here's your stored functions.

package MyFunctions;
# save this as MyFunctions.pm

sub say_hello {
  shift ;             # discard class name: perldoc perlboot
  print "Hello @_\n"
}

sub list_dir {
  shift ;             # discard class name

  require Cwd;
  my $owd = Cwd::cwd();
  my $dir = shift;
  chdir $dir or die "chdir $dir: $!\n";

  print $_ . "\n" while <*> ;
   
  chdir $owd;
}


1;
[download]

And here's your program. Here, rather than fetching function names and function arguments from a database, we'll just get it from the user.

#!/usr/bin/perl
# save this as program.pl

use strict;
use warnings;
use MyFunctions;

print "action> " ;
chomp( my $action = <STDIN> );
print "args> ";
chomp( my $arg = <STDIN> );

MyFunctions->$action( $arg );
[download]

And here's how it might look when you run it

$ perl program.pl
action> list_dir
args> /tmp
foo
bar
baz
[download]

The advantage of storing all your functions in a file and calling them as class methods (i.e. MyFunction->say_hello() rather than MyFunction::say_hello()) is that you have control over what your program does. If your program fetches code from a database, or gets it from the user, then you no longer have control over your program's behavior.

Belden

I was wondering if it is possible to have a subroutine stored as a string and then used as a normal subroutine within a program at run-time.

Have you given sufficient consideration as to why you want to do that? Have you considered any alternatives? If the answer is 'yes' and 'yes' or if you are determined to go this route, you may stop reading this now.

Pulling and executing code directly from a database like that is bound to cause maintenance headaches. It might be more advantageous for you to specify a 'skeleton' subroutine in your code and 'clone' it if you want to define similar subroutines at a later time. The benefit of this approach is that you minimize the domain of valid inputs to your code Basic Coding Tips: Parsimonious Parameterization, and thereby simplify debugging and interpreting the acceptable range of outputs. Even inventing your own 'mini language' would be better than simply pulling in subroutines as strings, because you are basically saying you want your inputs to be any concievable set of perl instructions ... that can't be good.

To translate all this abstract talk into a perl code example, here is an example that creates numerous subroutines that get 'cloned' into your perl code at runtime.

I can imagine a lot of reasone why you want to do this. And this is actually a feature I like much at Perl. Even though I do not use it very often.

But you have to consider performance issues, if you have evaluated code inside the performance driver (i.e. critical loop) of your script. When Perl sees a variable in your evaluated string, it recompiles it every time . From my current knowledge, I think Perl does not know, if the variable and therefore the string has changed. If not, there is no need to recompile it. But I do not know, if I am up-to-date here.

Of course, there are solutions for this issue and I do not know, if performance aspects are critical for pander. I just wanted to mention it, since I one was at such a point of Perl programming: Performance tuning for evaluated code segments.

#! /usr/bin/perl -w

my $a = 'sub { $name = shift; return substr($name, 0, 1); }';
my $b = eval $a ;
print &$b("wiredrat");
[download]

2005-02-16 Janitored by Arunbear - added code tags, as per Monastery guidelines

You extend this a bit, and you have what is called an "API". You extend it further, and you get a mini language.

IMO, the original post isn't quite screaming (maybe loudly speaking) for a mini language, but if robustness is an important issue, a mini language may be in order. Using eval is one thing, and may be great if all interactions to that column in the db is through a perl programmer. Using a mini language allows you to go the extra step and allow anyone to update it, assuming you have enough flexibility in your library of subroutines.

If you're going to go the mini-language route Module::Pluggable seems like a good choice.

I came across it with this simple introduction a couple of days ago.

Steve
---
steve.org.uk

hi you dont need to use eval although it is probably safer,

my $subref = sub {print "hello"};

&$subref();
[download]

artist wrote:

While it is possible as mentioned, I like to prefer a library of sub routines with specific names, that you can just include in your calling program. It may be easier to maintain and can provide less fear of wrong-doing or less debugging.

Fellow artist
I see this as a distributed library implementation. Would love to know about better ways of implementing this, so I can use this to my own projects.

Maybe the better approach would be to store and retrieve modules from the database, and overload use or require to correctly load your module from the database.

Anyway, I would love to read more about this approach, and about distributed shared perl modules.

-- monsieur_champs

Everybody else seems to be providing my $sub = eval "sub { $code }";. I've never used this method; heck, I've never even thought of doing it that way. It just seems unnatural to me to have it strung along in that manner. I do it the other way around: my $sub = sub { eval $code };. Besides, doing it this way allows for simpler error handling.

#!/usr/bin/perl -w

use strict;

my $code = q{ open( my $fh, '<', 'foo.txt' ) or die("open failed: $!")
+ };
my $sub = sub { eval($code) or die("error in eval(): $@"); };
$sub->();
[download]

The obvious downside is that this will only work for anonymous subs, and not named ones. The only way I can think of doing anything near 'named subs' is to abuse references, which is ugly:

#!/usr/bin/perl -w

use strict;

my $code = q{ open( my $fh, '<', 'foo.txt' ) or die("open failed: $!")
+ };
my $sub = sub { eval($code) or die("error in eval(): $@"); };

my $sub_name = 'do_this';

{
    no warnings 'once';
    no strict qw(refs vars);
    $$sub_name = $sub;
    $do_this->();
}
[download]

Putting the eval inside a sub can be must slower if that sub is called many times (more than once) since Perl will have to recompile $code each time the sub is called.

my $sub = eval "sub { $code }"; compiles the Perl code once, regardless of how many times you execute it.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

Something I don't think's been mentioned yet: remember that doing this won't preserve the closure-ness / binding of lexical variables.

And while possibly backwards from what you're trying to do you might look at Re: How to store CODE ref.