A module is a shared object that may be dynamically linked into the
interpreter at run-time to provide the interpreter with additional
intrinsic functions and variables. Several modules are distributed
with the stock version of the S-Lang library, including a
pcre module that allows the interpreter to make use of the
Perl Compatible Regular Expression library, a png
module that allows the interpreter to easily read and write PNG
files, and a rand module for producing random numbers.
There are also a number of modules for the interpreter that are not
distributed with the library. See
http://www.jedsoft.org/slang/modules/ for links to some of
those.
In order to make use of a module, it must first be ``imported'' into
the interpreter. There are two ways to go about this. One is to
use the import function to dynamically link-in the specified
module, e.g.,
import ("pcre");
pcre module and make its
symbols available to the interpreter using the active namespace.
However, this is not the preferred method for loading a module.
Module writers are encouraged to distribute a module with a file of
S-Lang code that performs the actual import of the module. Rather
than a user making direct use of the import function, the
preferred method of loading the modules is to load that file
instead. For example the pcre module is distributed with a
file called pcre.sl that contains little more than the
import("pcre") statement. To use the pcre module,
load pcre.sl, e.g.,
require ("pcre");
The main advantage of this approach to loading a module is that the
functionality provided by the module may be split between intrinsic
functions in the module proper, and interpreted functions contained
in the .sl file. In such a case, loading the module via
import would only provide partial functionality. The
png module provides a simple example of this concept. The
current version of the png module consists of a couple intrinsic
functions (png_read and png_write) contained in the
shared object (png-module.so), and a number of other
interpreted S-Lang functions defined in png.sl. Using the
import statement to load the module would miss the latter set
of functions.
In some cases, the symbols in a module may conflict with symbols
that are currently defined by the interpreter. In order to avoid
the conflict, it may be necessary to load the module into its own
namespace and access its symbols via the namespace prefix. For
example, the GNU Scientific Library Special Function module,
gslsf, defines a couple hundred functions, some with common
names such as zeta. In order to avoid any conflict, it is
recommended that the symbols from such a module be imported into a
separate namespace. This may be accomplished by specifying the
namespace as a second argument to the require function, e.g.,
require ("gslsf", "gsl");
.
.
y = gsl->zeta(x);
"gsl->".