Static values language extension proposal

[Facundo Domínguez]

Escuse me, the module export list was meant to be

> module Communicate(runExpect, runSend) where

Facundo

On Tue, Jan 28, 2014 at 5:13 PM, Facundo Domínguez
<facundo.dominguez at tweag.io> wrote:
> Hello Carter,
>   Thanks for the links. IIUC the ObjLink module contains an interface
> to the RTS linker. The points raised by Mathieu in his last email as
> (1a), (1b) and (2) still hold.
>
> Here's a use case for (2):
>
> module Communicate(run)
>
> import Control.Distributed.Process
>
> f :: Int -> Int
> f = id
>
> runSend :: Process ()
> runSend = send someone (static f)
>
> runExpect :: Int -> Process Int
> runExpect n = fmap (($ n) . unstatic) expect
>
> If any program tries to use runExpect, it would fail at runtime
> because it would fail to find `f`, because `f` is not exported and
> therefore a symbol for it would not appear in object files.
>
> The solution that modifies the compiler is superior to all workarounds
> we could think of to workaround this problem with a library. Any
> suggestions?
>
> Best,
> Facundo
>
> On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>> Theres actually a missing piece of information in this thread: what are the
>> example computations that are being sent?
>> My understanding is that erlang has not way to send file handles, shared
>> variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
>> pointers , and other fun unportable things between nodes, and I don't really
>> expect / see how we can hope to sanely do that in haskell!
>>
>> point in fact, even when restricted to "exactly the same binary, running on
>> a cluster of homogeneous machines with the exact same hardware, with a
>> modern linux distro " you hit some gnarly problems doing this for arbitrary
>> closures!  Its for a very simple (and fun) reason: address randomization!
>>
>> Nathan Howell was actually doing some experimentation with one strategy for
>> this special case here https://github.com/alphaHeavy/vacuum-tube  as a
>> deeply rts twiddling bit of hackery so you could in fact "serialize
>> arbitrary closures" between homogeneous machines running the exact same code
>> (and with address randomization disabled too i think)
>>
>> on the GHC API front,
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html
>> along with (and more appropriately
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
>> ) should actually give enough basic tooling to make this possible as a
>> userland library, mind you unload was recently fixed up in HEAD by Simon
>> Marlow to support the dynamic code loading / unloading use case he has in
>> facebook.  Point being the GHC 7.8 version of the ObjLink api should
>> actually give enough support tooling to prototype this idea in user land,
>> and that plus better support for writing "direct haskell code" and getting
>> out both a local computation and an AST we can serialize would probably be a
>> good set of primitives for making this feasible in user land.  I
>>
>> The meat of my point is 1) "yes I want this too" but also 2) one thing I
>> really have come to appreciate about how GHC is engineered is a lot of work
>> is done to provide the "right" primitives so that really really great tools
>> can be built in user land.  I think That the goal of this proposal can be
>> accomplished quite nicely with the  ObjLink module, unless i'm not
>> understanding something.  In Fact, because in general not every computation
>> will be properly serializable, you need not even bother with tracking an
>> explicit symbol table on each side, just try to load it at a given type and
>> if it fails it wasn't there!
>>
>> The point being, linkers are a thing, ghc exposes an API for linking, have
>> you tried that api?
>> http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>>
>>> On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m at tweag.io> wrote:
>>>>
>>>> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
>>>> <carter.schonwald at gmail.com> wrote:
>>>> > 1) you should (once 7.8 is out) evaluate how far you can push your
>>>> > ideas wrt
>>>> > dynamic loading as a user land library.
>>>> >  If you can't make it work as a library and can demonstrate why (or how
>>>> > even
>>>> > though it works its not quite satisfactory), thats signals something!
>>>>
>>>> Signals what?
>>>
>>>
>>> That there is a shortcoming in ghc and/or the rts that needs to be
>>> addressed.
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>