Idea: skip process handling

[etnt]

Hi, cool project.

Just an idea: Why not skip support for message send/receive? Mostly you use the gen_server.erl anyway and if you really want to send/receive you encapsulate that in your own Erlang module anyway.

[j14159]

Thanks!

Send/receive strikes me as a central feature for Erlang ("receive" is actually a part of the Core Erlang AST) and I wanted to work towards supporting all of those so that people would be able to use MLFE itself for as many things as possible. Missing items like try, catch, and error are all on my short-term TODO list with things like links in the medium term.

When it comes to OTP functionality like gen_server we actually need parameterized modules and an improved FFI to type properly. At a bare minimum we'd need things like parametric interfaces (like a very restrictive ML signature) that modules can implement and FFI extensions to type the server returned. I think this will unfortunately require a handful of explicit type annotations (at least for the interface) but it seems a small price to pay for an even more lightweight FFI with no Erlang code necessary to bridge it. A half-baked and potentially problem-laden interface might look like the following:

interface minimal_gen_server 'state 'messages 'replies

type call_result = (reply, 'replies, 'state) | (noreply, 'state)

init 'b:  'b -> (ok, 'state)

handle_call:  'messages -> pid _ -> 'state -> call_result

Where something like the FFI bridge for gen_server:start might look like:

type gen_server 'messages 'replies = GenServer pid 'messages

start 'a 'b 'c: minimal_gen_server 'a 'b 'c -> 'a -> gen_server 'b 'c
bridge start mod init = match gen_server.start(mod, init, []) with
  (ok, pid) -> GenServer pid

Here bridge would entail a fair bit of unification and I'm sure there are buckets of problems, not least of which is we're not actually capturing the 'replies type in that gen_server ADT properly but this is all off the cuff :)