I think the main problem is that the documentation is a little unclear as to what should syntactically be an atom, or if not an atom what it can/should evaluate to. Unfortunately it is not consistent.<br><br>So with<br><br>
    ExprF(Exp1, ... , ExprN)<br><br>ExprF should (syntactically) be an atom, or it should evaluate to a fun. That's it, no other options.<br><br>With <br><br>    ExprM:ExprF(Expr1,...,ExprN)<br><br>ExprM and ExprF should (syntactically) be atoms or evaluate to atoms. Again that's it.
<br><br>Originally it was actually a little more consistent as only the atom forms were allowed. So it was only foo(...) and foo:bar(...). For the case where they weren't atoms you had to use apply/2/3. You can view the forms when not atoms as syntactic sugar for apply (which they actually are):
<br><br>ExprF(Expr1 ... ExprN)   ==> apply(ExprF, [Expr1 ... ExprN])<br>ExprM:ExprF(Expr1 ... ExprN)   ==> apply(ExprM, ExprF, [Expr1 ... ExprN])<br><br>(but optimised so the argument lists are never built) Then it is consistent.
<br><br>Robert<br><br>P.S. Forget the {ExprM,ExprF} form for apply/2, it was a pseudo fun hack from before funs.<br><br><br><div><span class="gmail_quote">On 10/12/2007, <b class="gmail_sendername">Lovei Laszlo</b> <<a href="mailto:lovei@elte.hu">
lovei@elte.hu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi all!<br><br>A quote from the reference manual:<br><a href="http://www.erlang.org/doc/reference_manual/expressions.html#6.6">
http://www.erlang.org/doc/reference_manual/expressions.html#6.6</a><br><br>   6.6 Function Calls<br><br>   ExprF(Expr1,...,ExprN)<br>   ExprM:ExprF(Expr1,...,ExprN)<br><br>   ExprM should evaluate to a module name and ExprF to a function name
<br>   or a fun.<br>   [...]<br>   The module name can be omitted, if ExprF evaluates to the name of a<br>   local function, an imported function, or an auto-imported BIF.<br><br>This means that the following code is valid (F evaluates to a local
<br>function name):<br><br>   f() -> ok.<br>   g() -> F=f, F().<br><br>In practice, this aborts with the reason badfun. The question is, which<br>one is considered good: the manual, or the implementation?<br><br><br>
Thanks!<br>Laszlo<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">
http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br>