<div dir="ltr">I signed up for the mailing list to express my high level of interest in this project, I have been working with GHC 7.8 built as a cross compiler for Android and currently the only way to use libraries like lens, singletons, and anything else that uses Template Haskell is to add a patch to enable it in GHC during Stage1, and then to make drastic modifications to any cabal project source files that use TH and some hlint suggestions. Typically the current workflow for a cross-compiler is as follows:<br>
<div class="gmail_quote"><div dir="ltr">
<br>1. Cross GHC 7.8 using the Stage1 TH patch and a few other patches available from Neurocyte. These need to be updated slightly as they are for GHC 7.6, I can post updated patches if anyone else is curious. I would be very interested in cleaning up and integrating the needed changes into GHC, if cross Template Haskell is to be implemented.<br>
2. Create wrappers for hsc2hs and cabal for the cross compiler (I also have updated these)<br>3. Use a program called EvilSplicer on a log generated with 'cabal build --ghc-options=-ddump-splices 2>&1 | tee log' with the host compiler. This splices the host TH into the source files for use with the cross toolchain. You may notice this is cheating, and may not even work if the TH being generated is dependent on the target platform.<br>
4. Remove most hlint hints used with the ANN pragma. For some reason these cause GHC to load shared objects which cause it to immediately crash(probably because of the whole host system/target system mismatch). I was told this is related to the TemplateHaskell issue<br>
<br>Even getting lens to build is quite a chore, and I think with these changes, we could look forward to better iOS and Android support! I can't imagine the situation is much better for iOS devs at the moment.<br><br>
Again, I'd like to help get Android support polished, provided this change is ported and merged however I can :)<br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">This would probably be a great boon for those trying to use haskell for Android and IOS right? how might the emulation setup work for those?<div>
<br></div><div><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">wow, this is great work! <div><br></div><div>If theres a clear path to getting the generic tooling into 7.10, i'm all for it :) (and willing to help on concrete mechanical subtasks)</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman <span dir="ltr"><<a href="mailto:stegeman@gmail.com" target="_blank">stegeman@gmail.com</a>></span> wrote:<br></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div dir="ltr">hi all,<div><br></div><div>I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js)</div>
<div><br></div><div>Now besides the compiler having to do twice the work, this has some other disadvantages:</div><div><br></div><div>- Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages.</div>
<div>- The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants.</div><div><br></div><div>Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts).</div>
<div><br></div><div>How it works is pretty simple:</div><div><br></div><div>- When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script,</div>
<div>- GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server,</div><div>- for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message,</div>
<div>- the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification,</div><div>- the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances).</div>
<div><br></div><div>All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js.</div>
<div><br></div><div>Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices.</div>
<div><br></div><div>Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac.</div><div><br></div><div>cheers,</div><div><br></div><div>Luite</div><div><br></div><div>
[1] <a href="https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs" target="_blank">https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs</a></div>
<div>[2] <a href="https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs" target="_blank">https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs</a></div>
<div>[3] <a href="https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js" target="_blank">https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js</a></div>
<div>[4] <a href="https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29" target="_blank">https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29</a></div>
</div>
<br></div></div>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
<br></div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</div><br></div>