Static values language extension proposal

[Tim Watson]

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.