In Erlang programming Erlang code is divided into modules so the modules are the starting point of a process. It contains functions and attributes to access the information about the application (for ex: configuration parameters) and each function is terminated by dot (.)




square(N) when N>0 -> N * N;

square(0) -> 1.

 Module Attributes: In Erlang code module attributes consists a tag and a value,


Tag is an Atom and the Value is a literal term. The syntax of the literal Value is Name/Arity (here Name is an Atom and Arity is the number of arguments in integer format). And the term Name/Arity will be translated to {Name, Arity}.

After compiling the attributes will store in the compiled code and it will be called like this:

Module_name: function_name(attributes).

Different module attributes having its predefined meanings. Mostly modules have two attributes, but the user defined attributes must have one attribute.

 Here are some Pre-Defined Module Attributes:


Module_Name is the name of the module or we can say that the Module_Name is also known as file name which has the extension (.erl). This is the first attribute of Erlang file and having only mandatory attribute.

This is an exported function which will specify that the specified functions within the module are visible from outside the module.

import(Module_Name, Function_Name).

This will import the specified functions from the specified module name, and can be used like the local functions without using a module prefix. Module_Name is an atom and Function_Name is a list as for export.



Here Options may be single option or can be a list of options. And the attributes which are added in the option list after compiling the module.

Here Vsn is a literal term and can be retrieved from by using beam_lib:version/1. It is used to get the information about module version.


Here the function can be run automatically when a module is loaded.

Behaviour Module Attributes:

We can specify that the modules can be callback module for a behavior and used

like this:


The atom behavior gives the name of the behavior and it can be a user-defined

behavior or like OTP standard behaviours, here are some module versions:





We can use both the spelling behavior or behaviour. For example, the callback

functions of the module can be specified either directly or by exporting the

function behaviour_info/1:

behaviour_info(callbacks) -> Callbacks.

Or by a –callback attribute for each callback function:

callback Name(Arguments) -> Result.

In the above code, Arguments is a list or zero and can be more arguments.

Record Definitions:

It also have the same syntax as the module attributes are used, for ex:

-record(Record, Fields).

We can use Record definitions anywhere in the module and also in the function


Module_info/0 and module_info/1 functions: In each module compiler

automatically inserts two special exported functions, both are:



Both the functions is used to get information about the module. For ex:


It will returns a list of tuples {Key, Value} with the module information. Here the list

contains tuples with the following Keys: modules, attributes, compile, exports and


The number of tuples and the order can be change without prior notice.


The call module_info(Key) here Key is an atom and returns a single piece of

information about the module.

As a Key - following values are allowed:

module: this will return an atom which has the module name.

functions: this will return a list of tuples {Name, Arity} with all functions in the


export: this will return a list of tuples {Name, Arity} with all exported functions in the


attributes: this will return a list of tuples {Attribute_Name, Value_List}.

Attribute_Name is the name of an attribute. And Value_List is a list of values. And

remember one thing that the given attribute can execute more than one in the list

with the different values it the attribute occurs more than once in the module.

compile: this will return a list of tuples which have the information about how the

module was compiled.

native: if the module having native compiled code then it will return true otherwise


md5: this is used for binary representation of MD5 checksum of the module. But it

has a condition, if module has native code then this will be the MD5 of the native

code, not the BEAM bytecode.

  Modified On Dec-15-2017 03:08:59 AM

Leave Comment