Extending Process to handle reading messages in mailbox...

[GordonBGood]

Although the proposal at the bottom of "Process.elm" includes the ability to send messages to a process via its activation Id which messages end up in the process's mailbox array, there is no proposal on how to receive these messages.

The embedded Task doesn't know that it is running inside a Process, so doesn't know that there is a mailbox of messages one step up in the hierarchy (an adjacent leaf in the process object). One could pass any Process Task that needs to receive messages a function that knows how to retrieve the mailbox, but that opens the possibility that it is posted a mailbox from a different Process; it would be better if the current Process's mailbox is passed as a parameter.

Thus, it would seem that it would be better if there were a Process x a type to be used when one spawns a Process, with the succeed and fail functions creating this having the type signature as follows:

succeed : ((() -> Maybe msg) - > a) -> Process x a
fail : x -> Process x a
spawn : Process x a -> Task x (Id exit a)

where the inner thunk generates the next mailbox message each time it is called if there is one; in this way the process code has access to the mailbox items if there are any.

If there needs to be bidirectional communication, no further code would be required, as one could just send a message including a return address of the Id of another Process. Sending the Id's of two processes to each other would allow each to send messages (and respond) to the other.

There might need to be a few helper functions to assist the Process Task code decoding and responding to the successive mailbox messages, but they should be minor; the Process would still exit with Task x a (either by succeed or fail) to be processed with "andthen"'s or result or whatever.

This would work, and would be good if Javascript on which Elm is build were truly concurrent in a parallel sense; however, it is not and likely never will be. The closest it will get in the next several years will likely be asynch/await/Promises, which may be simpler than the above.

However, as the Process documentation now reads, the proposed changes with the above improvements could handle the case where earlier processes yield (as if to "await", to resume on the completion of a subsequent event) and on resuming send messages to subsequent Processes if they need what is provided, and even by batching many Task's into a list of Task's as one Task to cause awaiting of all of them, handling errors (if any), and producing results via the a parameter of the process Id.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[jvoigtlaender]

Please take this discussion/proposal to the mailing list.

[jvoigtlaender]

Please take this discussion/proposal to the mailing list.