Is there any way to define an Erlang function from within the Erlang shell instead of from an erl file?
+5
A:
Yes but it is painful. Below is a "lambda function declaration" (aka fun in Erlang terms).
1
>F=fun(X) -> X+2 end.
#Fun <erl_eval.6.13229925>
Have a look at this post. You can even enter a module's worth of declaration if you ever needed. In other words, yes you can declare functions.
jldupont
2010-01-14 17:15:11
Thanks, that worked. Do you know why the functions cannot be defined in the same way as they are in an erl file. Is it because "eval"ed code cannot "receive"? (I'm new to erlang so please correct me if what I am saying sounds like gibberish)
Zubair
2010-01-14 17:20:42
The example above is really a "lambda function declaration". Have a look at the articles I have linked in my answer: explanation is extensive.
jldupont
2010-01-14 17:24:42
I'm looking through those links now. Its starting to make sense :)
Zubair
2010-01-14 18:24:22
You can put a receive statement inside a fun.
Adam Lindberg
2010-01-14 20:25:31
When you start the console you start up a separate VM. An Erlang VM can no more receive on its own than a Java VM can. In a Java VM a class contains the code that receives. In an Erlang VM a function contains the code that receives.It isn't quite as REPL as Python or Ruby, but that isn't a bad thing once your thinking changes.
Jeffrey Hulten
2010-01-16 21:36:15
The shell process is a normal process with a Pid that you can send messages to. You can start an Erlang console and write a receive loop, and send to that process from another process you spawned, or from another Erlang node.
bjnortier
2010-08-20 12:28:18
+2
A:
One answer is that the shell only evaluates expressions and function definitions are not expressions, they are forms. In an erl file you define forms not expressions.
All functions exist within modules, and apart from function definitions a module consists of attributes, the more important being the modules name and which functions are exported from it. Only exported functions can be called from other modules. This means that a module must be defined before you can define the functions.
Modules are the unit of compilation in erlang. They are also the basic unit for code handling, i.e. it is whole modules which are loaded into, updated, or deleted from the system. In this respect defining functions separately one-by-one does not fit into the scheme of things.
Also, from a purely practical point of view, compiling a module is so fast that there is very little gain in being able to define functions in the shell.
rvirding
2010-01-16 00:25:13
Form is the name we gave to what you can have in a module file. So forms are both the attributes in a file, -module(), -export(), etc, and the function definitions. These are **not** expressions in that they are not evaluated and do not return values. We gave them the name forms so as to disinguish them from expressions.
rvirding
2010-01-21 21:39:01
A:
If you want to define a function on the shell to use it as macro (because it encapsulates some functionality that you need frequently), have a look at
Amadiro
2010-02-28 08:04:29