path: root/system/doc/reference_manual/modules.xml

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2003</year><year>2023</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.

    </legalnotice>

    <title>Modules</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
    <file>modules.xml</file>
  </header>

  <section>
    <title>Module Syntax</title>
    <p>Erlang code is divided into <em>modules</em>. A module consists
      of a sequence of attributes and function declarations, each
      terminated by period (.).</p>
      <p><em>Example:</em></p>
    <pre>
-module(m).          % module attribute
-export([fact/1]).   % module attribute

fact(N) when N>0 ->  % beginning of function declaration
    N * fact(N-1);   %  |
fact(0) ->           %  |
    1.               % end of function declaration</pre>
    <p>For a description of function declarations, see
    <seeguide marker="functions">Function Declaration Syntax</seeguide>.</p>
  </section>

  <section>
    <title>Module Attributes</title>
    <p>A <em>module attribute</em> defines a certain property of a
      module.</p>
    <p>A module attribute consists of a tag and a value:</p>
    <pre>
-Tag(Value).</pre>
    <p><c>Tag</c> must be an atom, while <c>Value</c> must be a literal
      term. As a convenience in user-defined attributes, if the literal term
      <c>Value</c> has the syntax <c>Name/Arity</c>
      (where <c>Name</c> is an atom and <c>Arity</c> a positive integer),
	  the term <c>Name/Arity</c> is translated to <c>{Name,Arity}</c>.</p>

    <p>Any module attribute can be specified. The attributes are stored
      in the compiled code and can be retrieved by calling
      <c>Module:module_info(attributes)</c>, or by using the module
      <seemfa marker="stdlib:beam_lib#chunks/2">beam_lib(3)</seemfa>
       in STDLIB.</p>

    <p>Several module attributes have predefined meanings.
      Some of them have arity two, but user-defined module
      attributes must have arity one.</p>

    <section>
      <title>Pre-Defined Module Attributes</title>
      <p>Pre-defined module attributes is to be placed before any
        function declaration.</p>
      <taglist>
        <tag><c>-module(Module).</c></tag>
        <item>
          <p>Module declaration, defining the name of the module.
            The name <c>Module</c>, an atom, is to be same as
            the file name minus the extension <c>.erl</c>. Otherwise
            <seeguide marker="code_loading#loading">code loading</seeguide> does
            not work as intended.</p>
          <p>This attribute is to be specified first and is the only
            mandatory attribute.</p>
        </item>
        <tag><c>-export(Functions).</c></tag>
        <item>
          <p>Exported functions. Specifies which of the functions,
            defined within the module, that are visible from outside
            the module.</p>
          <p><c>Functions</c> is a list
            <c>[Name1/Arity1, ..., NameN/ArityN]</c>, where each
            <c>NameI</c> is an atom and <c>ArityI</c> an integer.</p>
        </item>
        <tag><c>-import(Module,Functions).</c></tag>
        <item>
          <p>Imported functions. Can be called
            the same way as local functions, that is, without any module
            prefix.</p>
          <p><c>Module</c>, an atom, specifies which module to import
            functions from. <c>Functions</c> is a list similar as for
            <c>export</c>.</p>
        </item>
        <tag><c>-compile(Options).</c></tag>
        <item>
          <p>Compiler options. <c>Options</c> is a single option
            or a list of options.
            This attribute is added to the option list when
            compiling the module. See the <seeerl marker="compiler:compile">
            compile(3)</seeerl> manual page in Compiler.</p>
        </item>
        <tag><c>-vsn(Vsn).</c></tag>
        <item>
          <p>Module version. <c>Vsn</c> is any literal term and can be
            retrieved using <c>beam_lib:version/1</c>, see the
            <seemfa marker="stdlib:beam_lib#version/1">beam_lib(3)</seemfa>
            manual page in STDLIB.</p>
          <p>If this attribute is not specified, the version defaults
            to the MD5 checksum of the module.</p>
        </item>
        <tag><c>-on_load(Function).</c></tag>
        <item>
          <p>This attribute names a function that is to be run
            automatically when a
            module is loaded. For more information, see
	    <seeguide marker="code_loading#on_load">
            Running a Function When a Module is Loaded</seeguide>.</p>
        </item>
        <tag><marker id="nifs_attribute"/><c>-nifs(Functions).</c></tag>
        <item>
          <p>
            Specifies which of the functions, defined within the module, that
            may be loaded as NIFs with <seemfa marker="erts:erlang#load_nif/2">
            <c>erlang:load_nif/2</c></seemfa>.
          </p>
          <p>
            <c>Functions</c> is a list
            <c>[Name1/Arity1, ..., NameN/ArityN]</c>, where each
            <c>NameI</c> is an atom and <c>ArityI</c> an integer.
          </p>
          <p>While not strictly necessary, it is recommended to use <c>-nifs()</c>
          attribute in any module that load NIFs, to allow the compiler to make
          better decisions regarding optimizations.</p>
          <p>There is no need to add <c>-nifs([])</c> in modules that do not
          load NIFs. The lack of any call to
          <seemfa marker="erts:erlang#load_nif/2"><c>erlang:load_nif/2</c></seemfa>,
          from within the module, is enough for the compiler to draw the
          same conclusion.
          </p>
          <change>
            <p>
              The special meaning for the <c>-nifs()</c> attribute was
              introduced in Erlang/OTP 25.0. In previous releases, the
              <c>-nifs()</c> was accepted, but had no special meaning.
            </p>
          </change>
        </item>
      </taglist>
    </section>

    <section>
      <title>Behaviour Module Attribute</title>
      <p>It is possible to specify that the module is the callback
        module for a <em>behaviour</em>:</p>
      <pre>
-behaviour(Behaviour).</pre>
      <p>The atom <c>Behaviour</c> gives the name of the behaviour,
        which can be a user-defined behaviour or one of the following OTP
        standard behaviours:</p>
	<list type="bulleted">
	  <item><c>gen_server</c></item>
	  <item><c>gen_statem</c></item>
	  <item><c>gen_event</c></item>
	  <item><c>supervisor</c></item>
	</list>
      <p>The spelling <c>behavior</c> is also accepted.</p>
      <p>The callback functions of the module can be specified either
        directly by the exported function <c>behaviour_info/1</c>:</p>
        <pre>
behaviour_info(callbacks) -> Callbacks.</pre>
      <p>or by a <c>-callback</c> attribute for each callback
        function:</p>
      <pre>
-callback Name(Arguments) -> Result.</pre>
      <p>Here, <c>Arguments</c> is a list of zero or more arguments.
       The <c>-callback</c> attribute is to be preferred since the
       extra type information can be used by tools to produce
       documentation or find discrepancies.</p>
      <p>Read more about behaviours and callback modules in
        <seeguide marker="system/design_principles:spec_proc#behaviours">
        OTP Design Principles</seeguide>.</p>
    </section>

    <section>
      <title>Record Definitions</title>
      <p>The same syntax as for module attributes is used
        for record definitions:</p>
      <pre>
-record(Record,Fields).</pre>
      <p>Record definitions are allowed anywhere in a module,
        also among the function declarations.
	Read more in <seeguide marker="records">Records</seeguide>.</p>
    </section>

    <section>
      <title>Preprocessor</title>
      <p>The same syntax as for module attributes is used by
        the preprocessor, which supports file inclusion, macros,
	and conditional compilation:</p>
      <pre>
-include("SomeFile.hrl").
-define(Macro,Replacement).</pre>

      <p>Read more in <seeguide marker="macros">Preprocessor</seeguide>.</p>
    </section>

    <section>
      <title>Setting File and Line</title>
      <p>The same syntax as for module attributes is used for
        changing the pre-defined macros <c>?FILE</c> and <c>?LINE</c>:</p>
      <pre>
-file(File, Line).</pre>
      <p>This attribute is used by tools, such as Yecc, to inform the
        compiler that the source program is generated by another tool.
        It also indicates the correspondence of source files to lines of
        the original user-written file, from which the source program
        is produced.</p>
    </section>

    <section>
        <title>Types and function specifications</title>
	<p>A similar syntax as for module attributes is used for 
	specifying types and function specifications:
	</p>
	<pre>
-type my_type() :: atom() | integer().
-spec my_function(integer()) -> integer().</pre>
        <p>Read more in <seeguide marker="typespec">Types and Function specifications</seeguide>.
	</p>
	<p>
	  The description is based on
	    <url href="http://www.erlang.org/eeps/eep-0008.html">EEP8 -
	    Types and function specifications</url>,
	    which is not to be further updated.
	</p>
    </section>
  </section>

  <section>
    <title>
      The feature directive
    </title>

    <p>
      While not a module attribute, but rather a directive (since it
      might affect syntax), there is the <c>-feature(..)</c>
      directive used for enabling and disabling <seeguide
      marker="system/reference_manual:features#features">features</seeguide>.
    </p>
    <p>
      The syntax is similar to that of an attribute, but has two
      arguments:
    </p>
    <pre>
-feature(FeatureName, enable | disable).</pre>
    <p>
      Note that the <seeguide
      marker="macros#feature-directive">feature directive</seeguide>
      can only appear in a prefix of the module.
    </p>
  </section>

  <section>
    <title>Comments</title>
    <p>Comments can be placed anywhere in a module except within strings
      and quoted atoms. A comment begins with the character "%",
      continues up to, but does not include the next end-of-line, and
      has no effect. Notice that the terminating end-of-line has
      the effect of white space.</p>
  </section>

  <section>
    <title>module_info/0 and module_info/1 functions</title>

    <p>The compiler automatically inserts the two special, exported
      functions into each module:</p>
      <list type="bulleted">
	<item><c>Module:module_info/0</c></item>
	<item><c>Module:module_info/1</c></item>
      </list>
      <p>These functions can be called to retrieve information
        about the module.</p>

    <section>
      <title>module_info/0</title>
      <p>The <c>module_info/0</c> function in each module, returns
      a list of <c>{Key,Value}</c> tuples with information about
      the module. Currently, the list contain tuples with the following
      <c>Key</c>s: <c>module</c>, <c>attributes</c>, <c>compile</c>,
      <c>exports</c>, <c>md5</c> and <c>native</c>.
      The order and number of tuples
      may change without prior notice.</p>
    </section>

    <section>
      <title>module_info/1</title>
      <p>The call <c>module_info(Key)</c>, where <c>Key</c> is an atom,
       returns a single piece of information about the module.</p>

      <p>The following values are allowed for <c>Key</c>:</p>

      <taglist>
        <tag><c>module</c></tag>
	  <item>
	  <p>Returns an atom representing the module name.</p>
	  </item>

        <tag><c>attributes</c></tag>
	  <item>
	  <p>Returns a list of <c>{AttributeName,ValueList}</c> tuples,
	  where <c>AttributeName</c> is the name of an attribute,
	  and <c>ValueList</c> is a list of values. Notice that a given
	  attribute can occur more than once in the list with different
	  values if the attribute occurs more than once in the module.</p>

	  <p>The list of attributes becomes empty if
	  the module is stripped with the
	  <seemfa marker="stdlib:beam_lib#strip/1">beam_lib(3)</seemfa>
	  module (in STDLIB).</p>
	  </item>

        <tag><c>compile</c></tag>
	  <item>
	  <p>Returns a list of tuples with information about
	  how the module was compiled. This list is empty if
	  the module has been stripped with the
	  <seemfa marker="stdlib:beam_lib#strip/1">beam_lib(3)</seemfa>
	  module (in STDLIB).</p>
	  </item>

        <tag><c>md5</c></tag>
	  <item>
	  <p>Returns a binary representing the MD5 checksum of the module.</p>
	  </item>

        <tag><c>exports</c></tag>
	  <item>
	  <p>Returns a list of <c>{Name,Arity}</c> tuples with
	  all exported functions in the module.</p>
	  </item>

        <tag><c>functions</c></tag>
	  <item>
	  <p>Returns a list of <c>{Name,Arity}</c> tuples with
	  all functions in the module.</p>
	  </item>

        <tag><c>nifs</c></tag>
	  <item>
	  <p>Returns a list of <c>{Name,Arity}</c> tuples with
	  all NIF functions in the module.</p>
	  </item>

        <tag><c>native</c></tag>
	  <item>
	  <p>Return <c>true</c> if the module has native compiled code.
          Return <c>false</c> otherwise. In a system compiled without HiPE
          support, the result is always <c>false</c></p>
	  </item>
      </taglist>
    </section>
  </section>

</chapter>