{"id":399,"date":"2011-03-14T22:13:47","date_gmt":"2011-03-14T21:13:47","guid":{"rendered":"http:\/\/trigonakis.com\/blog\/?p=399"},"modified":"2011-03-14T22:43:30","modified_gmt":"2011-03-14T21:43:30","slug":"introduction-to-erlang-modules-compilation","status":"publish","type":"post","link":"http:\/\/trigonakis.com\/blog\/2011\/03\/14\/introduction-to-erlang-modules-compilation\/","title":{"rendered":"Introduction to Erlang : Modules & Compilation"},"content":{"rendered":"
This entry is part 6 of 16 in the series Introduction to Erlang<\/a><\/div>

Modules<\/h3>\n

A module<\/i> is a container for functions; it provided the contained functions with a common namespace. Modules are used to organize functions in Erlang. Usually, a program in Erlang spans over more than one modules. You can imagine a module as a package in Java, or a header file in C.<\/p>\n

Calling a Function<\/h3>\n

The calling convention in Erlang is module:function(argument1, argument2, ...)<\/code>. For example:<\/p>\n

\r\n1> lists:max([1,3,2]).\r\n3\r\n<\/pre>\n
Defining Modules<\/h3>\n
Lets say we want to create a module that will contain our own implementation of list functions and name it mlists<\/code>.
\n<\/p>\n
First, we create a file named mlists.erl<\/code> that will contain the module. The container file and the module names have to be the same<\/strong>.<\/p>\n
Calling a Module Function within the Module<\/h4>\n
A function defined within the module file can be called either as module_name:function(arguments)<\/code>, or function(arguments)<\/code>, so the module name can be skipped.<\/p>\n
Module Directives<\/h4>\n
Then we need to define the module’s attributes<\/i>. An attribute<\/i> is information that we provide to the Erlang compiler. It is placed as a directive (usually) in the top of the file and has the “-attribute_name(attribue_value(s)).<\/code>” format. The one attribute that we have to define is the one providing the module name. <\/p>\n
-module(…).<\/h5>\n
Defines the name of the module. For our example, in the top of mlists.erl<\/code> place:<\/p>\n
\r\n-module(mlists).\r\n<\/pre>\n
I repeat: the module name should be the same as the filename containing the module.<\/p>\n
-export([…])<\/h5>\n
More attributes are available to be passed to the compiler. A “necessary” one is the:<\/p>\n
\r\n-export([function1\/arity1, function2\/arity2, ...]).\r\n<\/pre>\n
that is used to define which functions the module exports, where “exports” means that they will be available to be called outside the module. Think of it as an Interface<\/code> in Java.<\/p>\n
All the functions that are not exported by the module are only visible within the file, similar with the private<\/code> functions in Java and the static<\/code> ones in C.<\/p>\n
-compile([…])<\/h5>\n
This one can be used to pass compilation instructions to the compiler. A usefull one is<\/p>\n
\r\n-compile([export_all]).\r\n<\/pre>\n
which automatically exports all the module’s functions. It is very convenient while developing and debugging, but you should not use it on production code, since the exported functions is the interface of your module, so you do not want to provide functions that are intended only for use within the module.<\/p>\n
-import(module_name, [function1\/arity1, function2\/arity2, …)<\/h5>\n
You can use this directive in order to import the selected exported functions of a module in the namespace of another one. That means that if you do so, you will be able to call the functions without the module prefix. Although in some cases it could be convenient, it is not recommended to use this directive, because it decreases the code’s readability.<\/p>\n
Other attributes<\/h5>\n
You can even define your own attributes. For example:<\/p>\n
\r\n-author(\"V. Trigonakis\").\r\n-date({2011, 03, 11}).\r\n<\/pre>\n
Example<\/h4>\n
\r\n-module(md).\r\n-export([same\/1, double\/1]).\r\n-author(\"Vasileios Trigonakis\").\r\n-date({2011, 03, 13}).\r\n\r\nsame(I) ->\r\n    I.\r\n\r\ndouble(N) ->\r\n    2 * N.\r\n\r\nnot_exported() ->\r\n    same(smthing),\r\n    double(123).\r\n<\/pre>\n
As you can see, this module has 3 functions and exports the 2 of them (same\/1, double\/1<\/code>).<\/p>\n
Compiling Modules<\/h3>\n
Emulator<\/h4>\n
Start an Erlang emulator on the folder that contains your source files. In order to compile a .erl<\/code> file you use the c(module_name)<\/code> Bult-in Function (BIF<\/strong>):<\/p>\n
\r\n1> c(md).\r\n.\/md.erl:12: Warning: function not_exported\/0 is unused\r\n{ok,md}\r\n<\/pre>\n
If no error occurs, the compiler generates the compiled .beam<\/code> file. In most of the cases, an Erlang warning indicates that something is not proper. For example, the warning for the md module can help us find that the not_exported\/0<\/code> function is neither exported, nor used within the file.<\/p>\n
\r\n2> ls().\r\nmd.beam     md.erl      md.erl~     \r\nok\r\n<\/pre>\n
You can also provide a path to the file to be compiled, or even move around folders using the cd(\"path\")<\/code> function.<\/p>\n
\r\n3> cd(\"..\").\r\n~\/Documents\/playing\/erlang\r\nok\r\n4> c(\"post_modules\/md\").\r\npost_modules\/md.erl:12: Warning: function not_exported\/0 is unused\r\n{ok,md}\r\n<\/pre>\n
Three other usefull utilities (functions) are the ls()<\/code>, pwd()<\/code>, and os:cmd(\"command\")<\/code> functions.<\/p>\n
\r\n1> pwd().\r\n\/var\r\nok\r\n2> ls().\r\nbackups     cache       crash       games       lib         local       \r\nlock        log         mail        opt         run         spool       \r\ntmp         \r\nok\r\n3> os:cmd(\"echo echoing...\").\r\n\"echoing...\\n\"\r\n<\/pre>\n
The last one executes the given command on a shell and returns the result.<\/p>\n
Erlang Compiler (erlc)<\/h4>\n
You can also use the Erl<\/strong>ang C<\/strong>ompiler to compile a module to a beam:<\/p>\n
\r\n$ ls\r\nmd.erl  md.erl~\r\n$ erlc md.erl\r\n.\/md.erl:12: Warning: function not_exported\/0 is unused\r\n$ ls\r\nmd.beam  md.erl  md.erl~\r\n<\/pre>\n
Loading a Module<\/h4>\n
You can load an already compiled module<\/p>\n
\r\n1> l(md).     \r\n{module,md}\r\n<\/pre>\n
Getting the Module’s Attributes<\/h4>\n
Every compiled module exports the module_info\/0<\/code> and module_info\/1<\/code> functions that can be used to fetch the attributes of a module.<\/p>\n
\r\n1> erlang:module_loaded(md).\r\nfalse\r\n2> l(md).\r\n{module,md}\r\n3> erlang:module_loaded(md).\r\ntrue\r\n4> md:module_info().\r\n[{exports,[{same,1},\r\n           {double,1},\r\n           {module_info,0},\r\n           {module_info,1}]},\r\n {imports,[]},\r\n {attributes,[{vsn,[205824271517095806442935620583334286333]},\r\n              {author,\"Vasileios Trigonakis\"},\r\n              {date,[{2011,3,13}]}]},\r\n {compile,[{options,[{cwd,\"~\/Documents\/playing\/erlang\/post_modules\"},\r\n                     {outdir,\"~\/Documents\/playing\/erlang\/post_modules\"}]},\r\n           {version,\"4.6.4\"},\r\n           {time,{2011,3,14,7,54,12}},\r\n           {source,\"~\/Documents\/playing\/erlang\/post_modules\/md.erl\"}]}]\r\n5> md:module_info(attributes).  \r\n[{vsn,[205824271517095806442935620583334286333]},\r\n {author,\"Vasileios Trigonakis\"},\r\n {date,[{2011,3,13}]}]\r\n<\/pre>\n
Next<\/h3>\n
I promise, from now on the posts will be far more interesting. Next one, or two posts will be about defining functions in Erlang. You can imagine how important functions are for a functional programming language.<\/storng><\/p>\n","protected":false},"excerpt":{"rendered":"
This entry is part 6 of 16 in the series Introduction to Erlang<\/a><\/div>
Modules A module is a container for functions; it provided the contained functions with a common namespace. Modules are used to organize functions in Erlang. Usually, a program in Erlang spans over more than one modules. You can imagine a module as a package in Java, or a header file in C. Calling a Function […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[40,51,28],"tags":[56,26,55,42],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1ouW6-6r","_links":{"self":[{"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/posts\/399"}],"collection":[{"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/comments?post=399"}],"version-history":[{"count":4,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/posts\/399\/revisions"}],"predecessor-version":[{"id":414,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/posts\/399\/revisions\/414"}],"wp:attachment":[{"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/media?parent=399"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/categories?post=399"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/trigonakis.com\/blog\/wp-json\/wp\/v2\/tags?post=399"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}