[erlang-questions] clarify: variable as function name

[Andreas Hillqvist]

I am missing the ability to send Variables to "fun [xxx:]yyy/z".

Something like:
    F = fun ExprF/0.

And:
    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
as the:
    F = fun yyy/0.
Or:
    F = fun xxx:yyy/0.


Another question: Should it be possible to bind BIF's to fun's not
specifying module?
    F = fun time/0.
Instead of:
    F = fun erlang:time/0.
I think it is OK like it is. But I take it up for discussion.


Kind regards,
Andreas Hillqvist

2007/12/10, Richard Carlsson <richardc@REDACTED>:
> 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
> miserably.
>
> - 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.
>
>   /Richard
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>