Static values language extension proposal

[Facundo Domínguez]

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
>