$ touch foo.pl
$ perl -we'use diagnostics; require "foo.pl"'
foo.pl did not return a true value at -e line 1 (#1)
    (F) A required (or used) file must return a true value to indicate
+ that
    it compiled correctly and ran its initialization code correctly.  
+It's
    traditional to end such a file with a "1;", though any true value 
+would
    do.  See perlfunc/require.

Uncaught exception from user code:
        foo.pl did not return a true value at -e line 1.
 at -e line 1
[download]

$ echo "a.pl did not return a true value at ./require.plx line 7." | s
+plain
a.pl did not return a true value at ./require.plx line 7 (#1)
    (F) A required (or used) file must return a true value to indicate
+ that
    it compiled correctly and ran its initialization code correctly.  
+It's
    traditional to end such a file with a "1;", though any true value 
+would
    do.  See perlfunc/require.
[download]

A module should end in a statement that evaluates to true. It is common to simply end your module with this:

1;
[download]

You'll have another challenge. Require doesn't import tpack(). Have a look at perlmod. That is the POD where you can read up on properly implementing a module. In specific, you're probably wanting for the module to export tpack(), and then for your main script to use instead of require(ing) the module.

Clearly, a.pl needs to return a true value. Any true value will do; conventionally the number 1 is used. Just add

return 1;
[download]

Often you'll see the return keyword omitted. Whether or not this is appropriate to do depends, again, on the specific structure of the file.

If you had read the documentation of require, you'd have seen these words:

The file must return true as the last statement to indicate successful execution of any initialization code, so it's customary to end such a file with 1; unless you're sure it'll return true otherwise. But it's better just to put the 1;, in case you add more statements.

See also this tutorial.

"without the mess of Module..."

What mess? Personally I find the use of required programs abhorable when creating modules is SOOOOOOO easy. While there are many things to consider when building a module for other programmer's consumption, just doing the following will get you a long way toward better more professional code:

Simply add the following lines to the top of your code:

package MyModule::Name;
require Exporter; 
use strict; 
use warnings; 
use vars qw( @ISA @EXPORT ); 
@ISA = qw( Exporter ); 
@EXPORT = qw( 
               func1
               func2
               func3
);
[download]

You'll want to replace MyModule::Name with your own app namespace and unique module name and then also replace the func1, func2, and func3 lines with the names ( and any additional ) functions your code has.

Then it's a simple:

use lib qw( /path/to/module/source ); 
use MyModule::Name;
[download]

in your application. What's so hard about that?

You'll also need to add a '1;' at the end of your source that has been mentioned here previously.

P.S. This is a simple example that does not take into consideration name space polution and other best practices.

My opinion of #include is that it's probably a considerably bigger mess than modules, with the possible exception of system related constants. I view the whole C/cpp #include|#if etc confabulation to be more than a little clunky, to the point of being a Bad Idea.

#!/usr/bin/perl -P
#include "aa"
print $aa;
[download]

$::aa = "Hi aa\n";
[download]

Be well,
Rob