Functionaly pure message passing

Not yet but I would very much like too.

It may be the case that the reply never comes if, e.g. the GenServer is (logically) waiting for some other call or cast before it decides to reply to the original caller.

Oh i’ll take a look at it. Did you ever try Elm? It is pretty nice to play with

So I have though about this quite a lot.

• It would be necessary to be able to send more than one message in response to a single incoming message
• You need to specify the address and the message
• An address needs to me more generic than a pid, i.e. it could be a http endpoint.

Finally having http as pure instructions where what led me to develop raxx. To model it like this you need a data structure for the request/response but that is a little of the core topic.

I think all the above points can be address with the following signature

spec handle(message, state) :: {[{address, message], state}

for example.

def handle({%HTTP.Request{path: "sign_up", body: email_address, from: client}}, state) do
  email = %Email{body: "Welcome name", target: email_address}
  mailer = state.mailer

  response = %HTTP.Response{status: 201}
  
  {[{mailer, email}, {client, response}], state}
end

Re dialyzer.

Because more than one spec can be added to a function I think you could specify a lot of information about the protocol

spec handle(:m1, :s1) :: {[:a, :m2], :s2}
spec handle(:m2, :s2) :: {[], :s1}

This says that the handle function does NOT handle the message :m1 when in state :s2

Addresses

I think addresses could be the same as you can use for genservers i.e. pid | atom | {:via, module, term}

comms

I have run some very basic experiments in this project. feel free to ignore, i didn’t get very far but would like to revisit the project one day GitHub - CrowdHailer/comms: Explicit message passing for improved reasoning about actor systems · GitHub

I stumbled across this a few times while writing Elixir code. I separated the code into processes that return actions, and processes that execute actions… I did not go further because it was a application that integrated GitHub and Slack and what really broke purity was HTTP calls. And writing a framework for doing it went well beyond the scope of the project.

That said I think Elm has a great approach to managing effects purely and could be a good inspiration I would love to collaborate on something similar for the backend

Now from a theoretical perspective, recursive types offer a basis for purely functional processes, that might be a solid starting point for more academic work, so I thought it is worth mentioning.

Roughly, a process is a function that takes a message and returns a reply and a new process (which is again a function that takes a message and … all the way down):

process :: message -> (message, process)

Does anyone know if dyalizer can check this kind of types?

Couldn’t you use an arbitrary {to, tag}?

i.e.

def test_gen_server_call(msg) do
  ref = make_ref()
  Server.handle_call(msg, {self(), ref}, nil)
  receive do
    {^ref, reply} -> assert_this_reply_is_correct(reply)
  end
end

This quote is pretty close to saying GenServer is valuable because of the ability to test by just calling one of the handle_calls and checking the return values. (Not true in every case, e.g. GenServer.reply/2)

Another interesting thing about what we did when separating the generic from the specific is that we instantly made it much easier to test our individual modules. If you wanted to unit test the old kitty server implementation, you’d need to spawn one process per test, give it the right state, send your messages and hope for the reply you expected. On the other hand, our second kitty server only requires us to run the function calls over the ‘handle_call/3’ and ‘handle_cast/2’ functions and see what they output as a new state. No need to set up servers, manipulate the state. Just pass it in as a function parameter. Note that this also means the generic aspect of the server is much easier to test given you can just implement very simple functions that do nothing else than let you focus on the behaviour you want to observe, without the rest.

Yep that is the kind of thing im looking for

Hah nice! That’s new!

So it is!

And it turns out someone has done some work on formally modelling and verifying BEAM message passing already.