I don't have time to weigh in on this proposal right now, but I have several comments... On 24 Jan 2014, at 17:19, Facundo Domínguez wrote:
Rationale =======
We want the language extension to meet the following requirements:
1. It must be a practical alternative to the remoteTable functions in the distributed-static package.
Agreed - this is vital!
2. It must not change the build scheme used for Haskell programs. A collection of .o files produced from Haskell source code should still be possible to link with the system linking tools.
Also vital.
3. It must not restrict all communicating processes using the extension to be launched from the same binary.
I personally think this is very valuable.
About the need for using different binaries ==============================
While using distributed-process we found some use cases for supporting communicating closures between multiple binaries.
One of these use cases involved a distributed application and a monitoring tool. The monitoring tool would need to link in some graphics libraries to display information on the screen, none of which were required by the monitored application. Conversely, the monitored application would link in some modules that the monitoring application didn’t need. Crucially, both applications are fairly loosely coupled, even if they both need to exchange static values about bindings in some modules they shared.
Indeed - this is an almost canonical use-case, as are administrative (e.g., remote management) tools.
As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won’t delve further into this problem.
Great idea.
Another possible line of work is extending this approach so a process can pull shared objects from a remote peer, when this remote peer sends a static value that is defined in a shared object not available to the process.
This would go a long way towards answering our questions about 'hot code upgrade' and be useful in many other areas too.