Is it possible to run erlang without compilation?

Question

Is there any VM for Erlang that allows you to do compilation on the fly instead of compiling before?

There is a possibility to compile from the shell, thanks Martin.

Now, from the Erlang shell (or some other module!):


1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe

Is there any pros or cons with doing this? Will you still be able to hot swap code? Is it the regular use-case to handle code? What benefits does the compiler give you in the end then?

Answer 1

From the Erlang shell, you can compile a module on the fly using c("path/to/module.erl") . You can also access this functionality through the compile module, specifically the compile:file/{1,2} functions.

For example, suppose we have a file mymod.erl :

-module(mymod).
-export([myfun/0]).

myfun() -> io:format("Hello Joe~n").

Now, from the Erlang shell (or some other module!):

1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe

See Erldocs on the compile module for more information.

You can do a great deal with the Erlang compiler in runtime. For example, you can dynamically generate code for a module (use erl_syntax !) and then compile it without even writing it to a file using compile:forms/{1,2} .

(Insert standard speech on great power and great responsibility.)

---

Will you still be able to hot swap code?

Yes.

Is it the regular use-case to handle code?

No. Normally Erlang code is compiled ahead of time into BEAM bytecode. Depending on whether Erlang was started in embedded or interactive mode, the modules are either loaded on startup, or dynamically as they are referenced. If you are building a release , you basically have to compile ahead of time.

What benefits does the compiler give you in the end then?

Well, for one thing, we can build compact releases without unnecessary components like the compiler. Of course, we also get all the traditional benefits of ahead-of-time compilation, particularly that of not having to waste time compiling all the time.

To sum it up, unless you fully understand the implications and have a very good reason not to compile your code ahead of time, please follow the standard practices.

Answer 2

The Erlang VM can only run compiled code! If you want to interpret Erlang code then you need an interpreter. The module erl_eval implements an Erlang interpreter and is part of the standard Erlang/OTP distribution. It is used by the Erlang shell to interpret the expressions entered.

All code handling in the Erlang VM, whether compiling, loading or updating, is done at the module level so it is impossible to compile or load a just one function. The Erlang compiler is written in Erlang and always available and can compile to either a file or a binary which can be immediately loaded into the system. As @MartinTörnwall has pointed out compiling a module from the shell using c(module) is in essence compiling on the fly.

So there would be no problems in automatically compiling code on the fly when it is used, at the module level. It is just that the current system is not designed to work that way and by default when it tries to load a module it only looks for the pre-compiled object file, the .beam file.

Answer 3

Erlang has an interpreter escript . Entire Erlang archive can be written in script. Almost all features are available.

By default, the script will be interpreted. You can force it to be compiled by including the -mode(compile). in the script.

Though it depends on the way you design your application, regular practice is to have .erl files which are compiled and run than having escript files.

So now you have many options.

1. Compile .erl file to .beam using c(my_module) this auto loads the .beam file. So the existing VM can run it on the fly. On in code you can use compile module functions like file, purge and load to load and run it on the fly.
2. Compile and keep the .erl files using erlc, erl -make, rebar, etc (Erlang has rich support) and then run it. You can build archives, boot scripts, rel etc to manage running and release of the Erlang software. This usually is the practice for production.
3. Use escript and run everything in interpreted mode.
4. Use escript and give -mode(compile) option to tell Erlang VM that at runtime (when starting to run escript) compile the code and run the compiled code (in memory)

Is there any pros or cons with doing this?

Compiled code is faster than interpreted code. I dont see any other right now in Erlang as pretty much everything is supported in both. Erlang even supports combination (Calling compiled code from interpreted code)

Will you still be able to hot swap code?

Yes in all cases. Your code also should be able to handle this.

Is it the regular use-case to handle code?

Option 2 for production. Option for 1 for learning / simple development. Option 3 and 4 in need basis for specific requirements (May be one time running).

What benefits does the compiler give you in the end then?

To make it clear, erlc program provides a common way to run all compilers in the Erlang system and compile module gives an interface to Erlang compilers. Compiler gives intermediate binary .beam file which helps in running Erlang code faster than interpreted counterpart. They also catch syntax errors (compilation errors).