A module is just a package with some conventions to make it easy to use as a library. One convention is to use the package name as filename so the library can be found, and to use .pm as suffix. Also depending on the module something like Exporter is used to export some function- or variable-names into the namespace of the script that is using the module.

See perlmod for more information

I read Coping with Scoping, wow what a great read .. I wish it had mentioned Modules as well.

That was outside the scope of that node :-)

But really packages don't interact very strongly with scoping. A package declaration really doesn't affect lexicals in any way.

package First;
my $x;
package Other:
print $x;  # still the same $x
[download]

Since our declarations really just provide lexical aliases for global storage locations, they interact in the same with packages as lexicals do - not at all. (Only the global storage location depends on the current package).

package First;
our $x;
package Other:
print $x;  # still the same $x
[download]

Only the fact that many packages live in files on their own affect scoping: each file is a scope of its own.

It's quite the same thing.

"Package" is the technical name for what is often called a "namespace" in other languages. It can be used as an object-oriented class, or just as a module, which is simply a bunch of definitions, usually of functions.

When talking about a module, especially a CPAN module, some kind of good order is often implied - a makefile, some documentation, a well-defined API, a test suite etc., although none of it is technically required.

In the last couple weeks, I've seen Perl questions on at least two separate forums which revolved around the connection between .pm files and Perl packages. Really, though, this connection is quite easy to understand if you just remember one thing:

It doesn't exist.

See Simple Module Tutorial, use, require, import, Exporter, perlmod