@EXPORT, @EXPORT_OK, and @EXPORT_FAIL are described in some detail in the perl documentation: see exporter.

@ISA is used to store the super classes of a class. For more information, on @ISA see perltoot.

Briefly, here's how the two fit together:

• @EXPORT stores the list of subroutines that are exported automatically whenever a user includes the module using use. Exporting lets you use subroutines without the full package qualification: so instead of Toys::Weeble::wobble(...) you can just use wobble(...). However, generally it is not a good idea to export things automatically. It can cause clashes with the names of subroutines in any code that uses your module.
• @EXPORT_OK stores the list of subroutines that can be optionally exported. Those who want to omit the package qualifier from the subroutine name can request the functions to be exported, by adding parameters to the use statement, like this: use Toys::Weeble qw(wobble wontFallDown);
• @EXPORT_FAIL are things you don't want exported. If a module tries to export any subroutine in that list, an error will be generated.

The actual exporting is done by a subroutine named import(...). It processes @EXPORT etc. It also takes the parameters to use and processes them. There is a default definition for it, so unless you want to do something special, you can pretty much forget about it and let the default subroutine do its thing. To get access to the default definition, you need to make your module a subclass of Exporter, hence the @ISA statement.

Best, beth

Update added explanation of how @ISA and @EXPORT etc work together.

As soon as you start using different namespaces through the package keyword, you will want to make function names available in other packages. Exporter is a common way to make function names available in other packages.

Your Module.pm doesn't set up a separate namespace from which functions may be imported by another package. All your functions are compiled into the caller's namespace:

Extending your Module.pm functions slightly

require Exporter;
@ISA = qw(Exporter);

@EXPORT =qw\fun1 fun2\;

@EXPORT_OK = qw\fun3\;

@EXPORT_FAIL= qw\fun4\;

sub fun1{print "\nfun1 in package " . __PACKAGE__ }
sub fun2{print "\nfun2 in package " . __PACKAGE__ }
sub fun3{print "\nfun3 in package " . __PACKAGE__ }
sub fun4{print "\nfun4 in package " . __PACKAGE__ }
[download]

the script

use Module;
fun1;
fun2;
fun3;
fun4;
[download]

outputs

fun1 in package main
fun2 in package main
fun3 in package main
fun4 in package main
[download]

Nothing exported, nothing imported. All is in the default package 'main'.

Use a package statement in your Module.pm:

package Module;
require Exporter;
@ISA = qw(Exporter);
...
[download]

Running the script again yields

fun1 in package Module
fun2 in package Module
[download]

The Exporter module implements an import method which allows a module to export functions and variables to its users' namespaces. Many modules use Exporter rather than implementing their own import method because Exporter provides a highly flexible interface, with an implementation optimised for the common case. Perl automatically calls the import method when processing a use statement for a module. Modules and use are documented in perlfunc and perlmod. Understanding the concept of modules and how the use statement operates is important to understanding the Exporter.

The arrays @EXPORT and @EXPORT_OK in a module hold lists of symbols that are going to be exported into the users name space by default, or which they can request to be exported, respectively. The symbols can represent functions, scalars, arrays, hashes, or typeglobs. The symbols must be given by full name with the exception that the ampersand in front of a function is optional,
Eg:
@EXPORT = qw(afunc $scalar @array); # afunc is a function
@EXPORT_OK = qw(afunc $scalar @array); # afunc is a function

Exports pollute the namespace of the module user. If you must export try to use @EXPORT_OK in preference to @EXPORT and avoid short or common symbol names to reduce the risk of name clashes.

The names of any symbols that cannot be exported should be listed in the @EXPORT_FAIL array. If a module attempts to import any of these symbols the Exporter will give the module an opportunity to handle the situation before generating an error. The Exporter will call an export_fail method with a list of the failed symbols.
Eg:
@failed_symbols = $module_name->export_fail(@failed_symbols);

If the export_fail method returns an empty list then no error is recorded and all the requested symbols are exported. If the returned list is not empty then an error is generated for each symbol and the export fails. The Exporter provides a default export_fail method which simply returns the list unchanged.

What is missing from your module code is the package statement. As you have it now, you just include module.pm into the same namespace as the main program, which makes all functions trivially accessible

Add a "package Module;" as the first line of your Module.pm and it should work as expected.

use Module;
fun1;
fun2;
fun3;
fun4;
[download]

fun1
fun2
fun3
fun4
[download]