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 <allber...@gmail.com>wrote: > On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug <m...@tweag.io> wrote: > >> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald >> <carter.schonw...@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 > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
