core erlang apply requires variable in function position?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

core erlang apply requires variable in function position?

Mikael Pettersson-5
This simple Core Erlang module fails to compile with OTP-20.0.1:

> cat test1.core
module 'test1' ['test1'/2]
    attributes []
'i'/1 =
  fun (_f) -> _f
'test1'/2 =
  fun (_f, _x) ->
    apply apply 'i'/1 (_f) (_x)
end
> erlc test1.core
no_file: Warning: invalid function call

and the .beam produced just contains code to throw a badfun error.

The warning comes from sys_core_fold:expr/3:

expr(#c_apply{anno=Anno,op=Op0,args=As0}=App, _, Sub) ->
    Op1 = expr(Op0, value, Sub),
    As1 = expr_list(As0, value, Sub),
    case Op1 of
        #c_var{} ->
            App#c_apply{op=Op1,args=As1};
        _ ->
            add_warning(App, invalid_call),
            ...

indicating that it's not prepared to handle apply forms with
anything but plain variables in the function position.  This
surprised me since:

1. I'm generating the above code using the cerl module's constructor
   functions which do not mention this restriction, and
2. the module so constructed passes core_lint:module/1, and
3. core_pp:format/1 is also happy with it, and
4. the Core Erlang language specification document doesn't
   restrict apply's function position beyond the general class
   of expressions.

So is this restriction deliberate or unintentional?

For now I work around it by wrapping the apply with a 'let'
binding the function position expression to a temporary.

/Mikael
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: core erlang apply requires variable in function position?

Dmytro Lytovchenko
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).

The decision itself whether to generate a call or an apply is made earlier in the compiler chain, and you're past it.

see cerl_cconv:apply_expr

2017-07-14 15:01 GMT+02:00 Mikael Pettersson <[hidden email]>:
This simple Core Erlang module fails to compile with OTP-20.0.1:

> cat test1.core
module 'test1' ['test1'/2]
    attributes []
'i'/1 =
  fun (_f) -> _f
'test1'/2 =
  fun (_f, _x) ->
    apply apply 'i'/1 (_f) (_x)
end
> erlc test1.core
no_file: Warning: invalid function call

and the .beam produced just contains code to throw a badfun error.

The warning comes from sys_core_fold:expr/3:

expr(#c_apply{anno=Anno,op=Op0,args=As0}=App, _, Sub) ->
    Op1 = expr(Op0, value, Sub),
    As1 = expr_list(As0, value, Sub),
    case Op1 of
        #c_var{} ->
            App#c_apply{op=Op1,args=As1};
        _ ->
            add_warning(App, invalid_call),
            ...

indicating that it's not prepared to handle apply forms with
anything but plain variables in the function position.  This
surprised me since:

1. I'm generating the above code using the cerl module's constructor
   functions which do not mention this restriction, and
2. the module so constructed passes core_lint:module/1, and
3. core_pp:format/1 is also happy with it, and
4. the Core Erlang language specification document doesn't
   restrict apply's function position beyond the general class
   of expressions.

So is this restriction deliberate or unintentional?

For now I work around it by wrapping the apply with a 'let'
binding the function position expression to a temporary.

/Mikael
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...