<div dir="ltr">My guess is that apply command in Core already implies that the code generator will emit apply/apply_last BEAM opcode which takes Arity * args, module in Arity'th and a function as Arity+1st register, i.e. there must be a register store command somewhere (which you do with a let).<div><br><div>The decision itself whether to generate a call or an apply is made earlier in the compiler chain, and you're past it.</div></div><div><br></div><div>see cerl_cconv:apply_expr</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-14 15:01 GMT+02:00 Mikael Pettersson <span dir="ltr"><<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This simple Core Erlang module fails to compile with OTP-20.0.1:<br>
<br>
> cat test1.core<br>
module 'test1' ['test1'/2]<br>
    attributes []<br>
'i'/1 =<br>
  fun (_f) -> _f<br>
'test1'/2 =<br>
  fun (_f, _x) -><br>
    apply apply 'i'/1 (_f) (_x)<br>
end<br>
> erlc test1.core<br>
no_file: Warning: invalid function call<br>
<br>
and the .beam produced just contains code to throw a badfun error.<br>
<br>
The warning comes from sys_core_fold:expr/3:<br>
<br>
expr(#c_apply{anno=Anno,op=<wbr>Op0,args=As0}=App, _, Sub) -><br>
    Op1 = expr(Op0, value, Sub),<br>
    As1 = expr_list(As0, value, Sub),<br>
    case Op1 of<br>
        #c_var{} -><br>
            App#c_apply{op=Op1,args=As1};<br>
        _ -><br>
            add_warning(App, invalid_call),<br>
            ...<br>
<br>
indicating that it's not prepared to handle apply forms with<br>
anything but plain variables in the function position.  This<br>
surprised me since:<br>
<br>
1. I'm generating the above code using the cerl module's constructor<br>
   functions which do not mention this restriction, and<br>
2. the module so constructed passes core_lint:module/1, and<br>
3. core_pp:format/1 is also happy with it, and<br>
4. the Core Erlang language specification document doesn't<br>
   restrict apply's function position beyond the general class<br>
   of expressions.<br>
<br>
So is this restriction deliberate or unintentional?<br>
<br>
For now I work around it by wrapping the apply with a 'let'<br>
binding the function position expression to a temporary.<br>
<br>
/Mikael<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>