<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 7, 2016 at 2:57 AM, Moritz Angermann <span dir="ltr"><<a href="mailto:moritz@lichtzwerge.de" target="_blank">moritz@lichtzwerge.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Great work Alberto,<br>
<br></blockquote><div> </div><div>Thanks :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I’m in favor of adding some form of network layer, as there are scenarios<br>
where you have to run the th compilation process on a different machine.<br>
This would be the case for iOS for example.<br>
<br>
When I toyed with this ~2years ago, trying to port the out of process th<br>
solution from ghcjs, I tried to use GHC’s plugin interface, to load the<br>
module that would allow ghc to communicate with the runner on the device.<br>
<br>
This in principle allows to have more dependencies on the plugin and not<br>
force them into ghc. At the same time it requires the installation of some<br>
additional hooks into the plugin system.<br>
<br>
I guess one could also come up with a tiny proxy that pretends to be the<br>
iserv endpoint and would forward anything over a network layer; this again<br>
could probably work outside of ghc.</blockquote><div><br></div><div>I'm pretty sure this can be done by adding networking capabilities to just iserv without adding networking capabilities to GHC itself.</div><div><br></div><div>However, I'm not sure if this could cause a linking problem if GHC requests iserv to load a different version of the "network" library than the one it was compiled against.</div><div><br></div><div>Cheers</div><div>Alberto</div></div></div></div>