Earlier quoted context omitted.
I suppose I was unclear. It is OTP-style `gen_server` processes that I'm talking about. > OTP processes communicate via the actor model by sending messages of any type. Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at compile time what type of message an actor can receive, what type it will send back, and ho…
I read the code but I'm not sure I understood all of it (I'm familiar with Elixir, not with Gleam). For normal matters I do believe that your approach works but (start returns the pid of the server, right?) what is it going to happen if something, probably a module written in Elixir or Erlang that wants to prove a point, sends a message of an unsupported type to that pid? I don't think the compiler can prevent that.…
Yes, `start` is the part you would stick in a supervision tree, essentially. We start the server so that it can be reached later with the interface functions.
> [...] probably a module written in Elixir or Erlang that wants to prove a point, sends a message of an unsupported type to that pid? I don't think the compiler can prevent that. It's going to crash at runtime or have to handle the unmatched type and return a not implemented sort of error.
Yes, this is already the default behavior of a `gen_server` and is fine, IMO. As a general guideline I would advise against trying to fix errors caused by type-unsafe languages; there is no productive (i.e. long-term fruitful) way to fix a fundamentally unsafe interface (Erlang/Elixir code), the best recourse you have is to write as much code you can in the safe one instead.
Erlang, in Gleam code, is essentially a layer where you put the code that does the fundamentals and then you use the foreign function interface (FFI) to tell Gleam that those functions can be called with so and so types, and it does the type checking. This means that once you travel into Erlang code all bets are off. It's really no different to saying that a certain C function can call assembly code.
pub type ProcessReference(message, term) {
ByPid(Pid(message))
ByGlobal(term)
ByLocal(Atom)
}
@external(erlang, "otp_server", "call")
fn gen_server_call(
pid: ProcessReference(message, term),
call_func: CallFunc(state, reply),
) -> Result(reply, Nil)
call({by_pid, Pid}, CallFunc) ->
{ok, gen_server:call(Pid, {call_by_func, CallFunc})};
call({by_global, Name}, CallFunc) ->
{ok, gen_server:call({global, Name}, {call_by_func, CallFunc})};
call({by_local, Name}, CallFunc) ->
{ok, gen_server:call(Name, {call_by_func, CallFunc})}.