Static values language extension proposal

[Carter Schonwald]

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.htmlalong
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140128/763dfca6/attachment-0001.html>