erlang backend function references

[sdancer]

to not kill hotloading, need to not hold fn() references, functions need to be called by module, function name, args

[lpil]

Hi @sdancer ! Could you expand upon this please? So everyone is on the same page. It'd be grand to hear any suggestions you have for how it would work too.

[sdancer]

• after 2 new recompiles of any module, the older version gets deleted, any process holding references to it get killed
• erlang function captures produce references to the module they are produced in
  a way to circumvent this problem is to refer to functions declared in modules by 2 atoms, modulename, and functionname and call the bif apply/3(modulename, functionname, args)
  would be good if can produce and use such "function pointers" while being type checked in the same way than anonymous functions are
  example

fn add(a: Int, b: Int) {
  a + b
}

fn sub(a: Int, b: Int) {
  a - b
}

fn use() {
  let funs = [fptr(add), fptr(sub)]
  list.map(funs, fn(f) { f(1, 2) })
}

the fptr here is just visual for example purposes, the compiler should be able to do with

  let funs = [add, sub]

the same should happen with constructors btw, which currently are being wrapped into an anonymous function

[lpil]

Thanks.

So is the general proposal that Gleam sometimes generates this

X = {mod, fn},
Y = apply(element(1, X), element(2, X), [A, B]).

in place of this

X = fun mod:fn/2,
Y = X(A, B).

?

Would it be opt-in or always? What might the syntax be?

There's performance considerations here as apply is slower.

Another thing to consider is that the type checking may be wrong in the context of hot code upgrades. There's no guarentee that the function has the same type in a mutable environment, this is why we've not any specific support for the upgrade mechanism in Gleam code, instead leaving it to be done in untyped Erlang.

[sdancer]

Another thing to consider is that the type checking may be wrong in the context of hot code upgrades. There's no guarentee that the function has the same type in a mutable environment, this is why we've not any specific support for the upgrade mechanism in Gleam code, instead leaving it to be done in untyped Erlang.

np, if the upgrade is planned, u get a chance to update anything from old to new in "code_load" and similar hooks, most people won't ever deal with this kind of stuff, the ones doing so should know what they are doing anyways
another thing is, the api versioning that i mentioned on the chat earlier could help here, as some extra safety assurance(less chance of crashing stuff accidentally)

X = {function_ref, mod, fn},
Y = apply(element(1, X), element(2, X), [A, B]).

i would add a record there for the purpose of debug help, as for performance, around otp 20 the cost of apply was the same of a remote call(normal call to other module), not sure nowadays with the jit and etc

[lpil]

np, if the upgrade is planned, u get a chance to update anything from old to new in "code_load" and similar hooks, most people won't ever deal with this kind of stuff, the ones doing so should know what they are doing anyways

I'm familiar with the API aye, but from my little thought experiment if we applied type checking here it would not be possible to do it correctly because the type checker would incorrectly force you to adhere to the newer types rather than work with both. What do you think that callback would look like implemented in Gleam?

as for performance, around otp 20 the cost of apply was the same of a remote call(normal call to other module)

That's good to know, I didn't know that. Thanks

Would you want this behaviour to be opt-in?

[sdancer]

i would prefer this to be the default behavior, its commonly used everywhere in erlang otp and elixir
example

a = Mod
a.b("hello")

[sdancer]

but from my little thought experiment if we applied type checking here it would not be possible to do it correctly because the type checker would incorrectly force you to adhere to the newer types rather than work with both.

to do that u keep a copy of the old struct typedef, and new, and on code_load do old -> new

[lpil]

i would prefer this to be the default behavior, its commonly used everywhere in erlang otp and elixir
example

Sorry, I am confused. That example is not the same as the above?

to do that u keep a copy of the old struct typedef, and new, and on code_load do old -> new

So you'd manually copy the definition over to have a before and after version?

[sdancer]

ye, if need to upgrade a struct in gleam, would most likely need to do that, or serialize to json/similar, even when its not about code hotload, example, saving/loading ets/mnesia