Static values language extension proposal
watson.timothy at gmail.com
Fri Jan 24 18:06:58 UTC 2014
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:
> 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.
> 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.
> 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.
More information about the Glasgow-haskell-users