GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
hi all, 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) Now besides the compiler having to do twice the work, this has some other disadvantages: - 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. - 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. 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). How it works is pretty simple: - 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, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - 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, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). 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. 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. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
wow, this is great work! 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) On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman wrote: > hi all, > > 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) > > Now besides the compiler having to do twice the work, this has some other > disadvantages: > > - 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. > - 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. > > 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). > > How it works is pretty simple: > > - 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, > - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, > the script starts a Haskell thread running the server, > - 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, > - the runner loads and runs the code in the Q monad, can send queries to > GHCJS for reification, > - the runner sends back the result as a serialized Template Haskell AST > (using GHC.Generics for the Binary instances). > > 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. > > 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. > > Thanks to Andras Slemmer from Prezi who helped build the initial proof of > concept (without reification) at BudHac. > > cheers, > > Luite > > [1] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > [2] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs > [3] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js > [4] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
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? On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald wrote: > wow, this is great work! > > 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) > > > On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman > wrote: > >> hi all, >> >> 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) >> >> Now besides the compiler having to do twice the work, this has some other >> disadvantages: >> >> - 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. >> - 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. >> >> 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). >> >> How it works is pretty simple: >> >> - 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, >> - GHCJS sends its RTS and the Template Haskell server code [1] to >> node.js, the script starts a Haskell thread running the server, >> - 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, >> - the runner loads and runs the code in the Q monad, can send queries to >> GHCJS for reification, >> - the runner sends back the result as a serialized Template Haskell AST >> (using GHC.Generics for the Binary instances). >> >> 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. >> >> 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. >> >> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >> concept (without reification) at BudHac. >> >> cheers, >> >> Luite >> >> [1] >> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >> [2] >> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >> [3] >> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >> [4] >> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Yes! This would definitely be of great interest to users of the Android cross compilers. It should be quite feasible to drive a TH runner process on a development device or emulator. Having genuine TH support would be a huge improvement to the usefulness of GHC in a cross compiling scenario. I would love to start work on integrating TH runner support into ghc-android. On 2014-07-02 18:14, Luite Stegeman wrote: > 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. > -- CJ van den Berg mailto:c...@vdbonline.com xmpp:neuroc...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I think GHC could use more or less the same communication method as GHCJS now does: Start some user-specifiied process and send messages through pipes (GHCJS uses stdin/stderr of the node process), with the difference that it would get dynamic libraries for the target rather than blobs of JS code. That user process is then responsible for setting up the actual communication with the runner on the emulator or development device. A requirement for complete TH support is that more code can be loaded at runtime, so that multiple splices can be run by the same runner (because of the persistent map, qGetQ / qPutQ), I'm not sure if this is problematic on iOS. On Thu, Jul 3, 2014 at 2:54 AM, Carter Schonwald wrote: > 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? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> wow, this is great work! >> >> 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) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >> >>> hi all, >>> >>> 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) >>> >>> Now besides the compiler having to do twice the work, this has some >>> other disadvantages: >>> >>> - 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. >>> - 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. >>> >>> 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). >>> >>> How it works is pretty simple: >>> >>> - 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, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - 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, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> 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. >>> >>> 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. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof >>> of concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
In case anyone wanted to start writing haskell android code now, jhc fully supports android as a target. here is an app made with it https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube this was made with Kiwamu's ajhc branch but code has been merged back into the main tree. On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald wrote: > 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? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald > wrote: >> >> wow, this is great work! >> >> 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) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >>> >>> hi all, >>> >>> 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) >>> >>> Now besides the compiler having to do twice the work, this has some other >>> disadvantages: >>> >>> - 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. >>> - 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. >>> >>> 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). >>> >>> How it works is pretty simple: >>> >>> - 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, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - 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, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> 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. >>> >>> 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. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>> concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mail
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Hello John, I tried to install the Haskell demo Cube on my Nexus 7 and got: Error: package file was not signed correctly. D On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: > In case anyone wanted to start writing haskell android code now, jhc > fully supports android as a target. here is an app made with it > > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > > this was made with Kiwamu's ajhc branch but code has been merged back > into the main tree. > > On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > wrote: >> 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? >> >> >> >> >> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >> wrote: >>> >>> wow, this is great work! >>> >>> 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) >>> >>> >>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >>> wrote: hi all, 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) Now besides the compiler having to do twice the work, this has some other disadvantages: - 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. - 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. 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). How it works is pretty simple: - 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, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - 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, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). 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. 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. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> ___ >> Glasgow-haskel
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
On Thu, Jul 3, 2014 at 6:18 PM, Simon Peyton Jones wrote: > Luite > > > > I lack the bandwidth to respond at any technical depth, but I’d like to > make encouraging noises. If you can figure out a way to make GHC do these > things without making the compiler terribly complicated and making > maintaining it harder, then I’m open to your proposals. > > > I think most of the communication code could go into a separate executable that can be built by the user for the target-specific communication. The GHC API facing part of the implementation in GHCJS is under 300 lines and that includes some non-exported code duplicated from GHC, so I'm reasonably optimistic that it can be done without too much impact. Unfortunately I won't have much time in the near future, since a GHCJS release is well overdue (mostly because I keep adding features like this...) and I want to focus on that first, but getting it ready before 7.10 should be doable (especially if other people want to help!) luite ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Hmm.. It works on my nexus 4. Kiwamu of the metasepi http://ajhc.metasepi.org/ is the one that uploaded the demo. Perhaps he needs to update the key or something. On Thu, Jul 3, 2014 at 9:43 PM, Dominick Samperi wrote: > Hello John, > I tried to install the Haskell demo Cube on my Nexus 7 > and got: Error: package file was not signed correctly. > D > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: >> In case anyone wanted to start writing haskell android code now, jhc >> fully supports android as a target. here is an app made with it >> >> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube >> >> this was made with Kiwamu's ajhc branch but code has been merged back >> into the main tree. >> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald >> wrote: >>> 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? >>> >>> >>> >>> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >>> wrote: wow, this is great work! 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) On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman wrote: > > hi all, > > 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) > > Now besides the compiler having to do twice the work, this has some other > disadvantages: > > - 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. > - 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. > > 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). > > How it works is pretty simple: > > - 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, > - GHCJS sends its RTS and the Template Haskell server code [1] to > node.js, the script starts a Haskell thread running the server, > - 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, > - the runner loads and runs the code in the Q monad, can send queries to > GHCJS for reification, > - the runner sends back the result as a serialized Template Haskell AST > (using GHC.Generics for the Binary instances). > > 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. > > 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. > > Thanks to Andras Slemmer from Prezi who helped build the initial proof of > concept (without reification) at BudHac. > > cheers, > > Luite > > [1] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > [2] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs > [3] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js > [4] > https://github.com/ghcjs/ghc
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
It installed and worked on my Nexus 5. On 2014-07-04 00:43, Dominick Samperi wrote: > Hello John, > I tried to install the Haskell demo Cube on my Nexus 7 > and got: Error: package file was not signed correctly. > D > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: >> In case anyone wanted to start writing haskell android code now, jhc >> fully supports android as a target. here is an app made with it >> >> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube >> >> this was made with Kiwamu's ajhc branch but code has been merged back >> into the main tree. >> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald >> wrote: >>> 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? >>> >>> >>> >>> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >>> wrote: wow, this is great work! 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) On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman wrote: > hi all, > > 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) > > Now besides the compiler having to do twice the work, this has some other > disadvantages: > > - 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. > - 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. > > 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). > > How it works is pretty simple: > > - 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, > - GHCJS sends its RTS and the Template Haskell server code [1] to > node.js, the script starts a Haskell thread running the server, > - 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, > - the runner loads and runs the code in the Q monad, can send queries to > GHCJS for reification, > - the runner sends back the result as a serialized Template Haskell AST > (using GHC.Generics for the Binary instances). > > 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. > > 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. > > Thanks to Andras Slemmer from Prezi who helped build the initial proof of > concept (without reification) at BudHac. > > cheers, > > Luite > > [1] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > [2] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs > [3] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js > [4] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 > > ___ >
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
does JHC support template haskell? On Sat, Jul 5, 2014 at 12:02 PM, Scott Turner <2hask...@pkturner.org> wrote: > It installed and worked on my Nexus 5. > > On 2014-07-04 00:43, Dominick Samperi wrote: > > Hello John, > > I tried to install the Haskell demo Cube on my Nexus 7 > > and got: Error: package file was not signed correctly. > > D > > > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: > >> In case anyone wanted to start writing haskell android code now, jhc > >> fully supports android as a target. here is an app made with it > >> > >> > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > >> > >> this was made with Kiwamu's ajhc branch but code has been merged back > >> into the main tree. > >> > >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > >> wrote: > >>> 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? > >>> > >>> > >>> > >>> > >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald > >>> wrote: > wow, this is great work! > > 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) > > > On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman > wrote: > > hi all, > > > > 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) > > > > Now besides the compiler having to do twice the work, this has some > other > > disadvantages: > > > > - 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. > > - 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. > > > > 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). > > > > How it works is pretty simple: > > > > - 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, > > - GHCJS sends its RTS and the Template Haskell server code [1] to > > node.js, the script starts a Haskell thread running the server, > > - 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, > > - the runner loads and runs the code in the Q monad, can send > queries to > > GHCJS for reification, > > - the runner sends back the result as a serialized Template Haskell > AST > > (using GHC.Generics for the Binary instances). > > > > 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. > > > > 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. > > > > Thanks to Andras Slemmer from Prezi who helped build the initial > proof of > > concept (without reification) at BudHac. > > > > cheers, > > > > Luite > > > > [1] > > > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > > [2] > > > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Pr
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald wrote: > does JHC support template haskell? Pretty sure TH is too closely tied to ghc. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Actually, I was looking into it a little, and template haskell could effectively be implemented by a pre-processor and a portable library that is compiler independent. If one could get ghc to spit out the template haskell source after it expands it then that can be fed to jhc as a quick first pass, but ideally the pre-processor TH would create programs that can be run under the target compiler. that would bring TH to every haskell compiler. John On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery wrote: > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > wrote: >> >> does JHC support template haskell? > > > Pretty sure TH is too closely tied to ghc. > > -- > brandon s allbery kf8nh sine nomine associates > allber...@gmail.com ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
How would you do reification with that approach? On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > wrote: > > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > > wrote: > >> > >> does JHC support template haskell? > > > > > > Pretty sure TH is too closely tied to ghc. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allber...@gmail.com > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
The target compiler would have the TH libraries, which could be made to be portable. The external program would just extract the TH bits and turn them into a program that spits the TH expanded output to a new file to compile, and repeat the process til no TH expansions exist and finally that is the result you pass to the compiler. John On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman wrote: > How would you do reification with that approach? > > > On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: >> >> Actually, I was looking into it a little, and template haskell could >> effectively be implemented by a pre-processor and a portable library >> that is compiler independent. If one could get ghc to spit out the >> template haskell source after it expands it then that can be fed to >> jhc as a quick first pass, but ideally the pre-processor TH would >> create programs that can be run under the target compiler. that would >> bring TH to every haskell compiler. >> >> John >> >> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery >> wrote: >> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald >> > wrote: >> >> >> >> does JHC support template haskell? >> > >> > >> > Pretty sure TH is too closely tied to ghc. >> > >> > -- >> > brandon s allbery kf8nh sine nomine >> > associates >> > allber...@gmail.com >> > ballb...@sinenomine.net >> > unix, openafs, kerberos, infrastructure, xmonad >> > http://sinenomine.net >> >> >> >> -- >> John Meacham - http://notanumber.net/ >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I'm not sure I correctly understand your approach, but to have the template haskell reification work without any runtime communication with the compiler you'd have to include the entire typechecker state, at least for all names reachable from the splice (see http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html , the Quasi class for the required functionality). This would mean serializing all names with types modules, annotations, instances. I briefly looked into this for GHCJS but decided that just querying the compiler would be better. On Sat, Jul 5, 2014 at 10:39 PM, John Meacham wrote: > The target compiler would have the TH libraries, which could be made > to be portable. The external program would just extract the TH bits > and turn them into a program that spits the TH expanded output to a > new file to compile, and repeat the process til no TH expansions exist > and finally that is the result you pass to the compiler. > > John > > On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman wrote: > > How would you do reification with that approach? > > > > > > On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: > >> > >> Actually, I was looking into it a little, and template haskell could > >> effectively be implemented by a pre-processor and a portable library > >> that is compiler independent. If one could get ghc to spit out the > >> template haskell source after it expands it then that can be fed to > >> jhc as a quick first pass, but ideally the pre-processor TH would > >> create programs that can be run under the target compiler. that would > >> bring TH to every haskell compiler. > >> > >> John > >> > >> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > >> wrote: > >> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > >> > wrote: > >> >> > >> >> does JHC support template haskell? > >> > > >> > > >> > Pretty sure TH is too closely tied to ghc. > >> > > >> > -- > >> > brandon s allbery kf8nh sine nomine > >> > associates > >> > allber...@gmail.com > >> > ballb...@sinenomine.net > >> > unix, openafs, kerberos, infrastructure, xmonad > >> > http://sinenomine.net > >> > >> > >> > >> -- > >> John Meacham - http://notanumber.net/ > >> ___ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users@haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > > > -- > John Meacham - http://notanumber.net/ > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Zeroth takes the first approach. It only supports a subset of TH (DecsQ splices) however. http://hackage.haskell.org/package/zeroth https://github.com/aavogt/zeroth is a fork that works with more recent haskell-src-exts and ghc On Sat, Jul 5, 2014 at 3:59 PM, John Meacham wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery wrote: >> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald >> wrote: >>> >>> does JHC support template haskell? >> >> >> Pretty sure TH is too closely tied to ghc. >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allber...@gmail.com ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I created a GHC patch that spits out the generated Template Haskell code to a file with -dump-to-file -ddump-splices https://ghc.haskell.org/trac/ghc/ticket/9126 On Sat, Jul 5, 2014 at 8:18 PM, adam vogt wrote: > Zeroth takes the first approach. It only supports a subset of TH > (DecsQ splices) however. > > http://hackage.haskell.org/package/zeroth > > https://github.com/aavogt/zeroth is a fork that works with more recent > haskell-src-exts and ghc > > On Sat, Jul 5, 2014 at 3:59 PM, John Meacham wrote: > > Actually, I was looking into it a little, and template haskell could > > effectively be implemented by a pre-processor and a portable library > > that is compiler independent. If one could get ghc to spit out the > > template haskell source after it expands it then that can be fed to > > jhc as a quick first pass, but ideally the pre-processor TH would > > create programs that can be run under the target compiler. that would > > bring TH to every haskell compiler. > > > > John > > > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > wrote: > >> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > >> wrote: > >>> > >>> does JHC support template haskell? > >> > >> > >> Pretty sure TH is too closely tied to ghc. > >> > >> -- > >> brandon s allbery kf8nh sine nomine > associates > >> allber...@gmail.com > ballb...@sinenomine.net > >> unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > > > > > -- > > John Meacham - http://notanumber.net/ > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
