[erlang-questions] clarify: variable as function name
Mon Dec 10 13:47:31 CET 2007
I am missing the ability to send Variables to "fun [xxx:]yyy/z".
F = fun ExprF/0.
F = fun ExprM:ExprF/0.
Where the look up to a function is performed only once when the fun
operation is executed. And where calls to F() should be as fast/slow
F = fun yyy/0.
F = fun xxx:yyy/0.
Another question: Should it be possible to bind BIF's to fun's not
F = fun time/0.
F = fun erlang:time/0.
I think it is OK like it is. But I take it up for discussion.
2007/12/10, Richard Carlsson <>:
> Lovei Laszlo wrote:
> > 6.6 Function Calls
> > ExprF(Expr1,...,ExprN)
> > ExprM:ExprF(Expr1,...,ExprN)
> > ExprM should evaluate to a module name and ExprF to a function name
> > or a fun.
> > [...]
> > The module name can be omitted, if ExprF evaluates to the name of a
> > local function, an imported function, or an auto-imported BIF.
> > This means that the following code is valid (F evaluates to a local
> > function name):
> > f() -> ok.
> > g() -> F=f, F().
> > In practice, this aborts with the reason badfun. The question is, which
> > one is considered good: the manual, or the implementation?
> The implementation, most definitely. The reference manual apparently
> tries to give a very condensed description of function calls, and fails
> - The two forms ExprF(Expr1,...,ExprN) and ExprM:ExprF(Expr1,...,ExprN)
> need to be explained separately; they are too different.
> - In the case of a call ExprF(Expr1,...,ExprN):
> * ExprF can be a constant atom (lexically), or otherwise it must
> be an expression which evaluates to a fun. Nothing else is
> possible. (In particular, no dynamically computed atoms.)
> ExprF usually needs parentheses around it if it is not an
> atom or a variable.
> * The handling of the constant atom thing is as follows: If the
> code contains <atom>(a1,...,aN), and <atom>/N is the name of a
> function imported (explicitly or automatically) from module M,
> then the call is rewritten as M:<atom>(a1,...,aN). Otherwise,
> the function <atom>/N must be a locally defined function, and
> the call is equivalent to (fun <atom>/N)(a1,...,aN).
> * This slight syntactic weirdness is due to the fact that lexically,
> Erlang uses atoms, not variables, to name functions. It's a
> remnant from Erlang's roots in Prolog. It gets strange sometimes
> but we can live with it.
> - In the case of a remote call ExprM:ExprF(Expr1,...,ExprN):
> * ExprF must evaluate to an atom; it cannot be a fun.
> * ExprM must evaluate to an atom (or, inofficially, to a value that
> represents an instance of an abstract module).
> * It does not matter if ExprM and ExprF are lexically atoms or not.
> However, the compiler can generate a bit more efficient code
> if both ExprM and ExprF are known at compile time.
> erlang-questions mailing list
More information about the erlang-questions