<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>There is <a href="https://github.com/ghc-proposals/ghc-proposals">https://github.com/ghc-proposals/ghc-proposals</a><br><br>Sent from my iPhone</div><div><br>On 25 Nov 2016, at 11:30 PM, Shea Levy <<a href="mailto:shea@shealevy.com">shea@shealevy.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> writes:</span><br><span></span><br><blockquote type="cite"><span>The right thing is to have a clean separation between runtime</span><br></blockquote><blockquote type="cite"><span>imports and compile-time imports. Perhaps we just annotate some imports to</span><br></blockquote><blockquote type="cite"><span>say they aren't needed at compile-time for running the TH code. but then</span><br></blockquote><blockquote type="cite"><span>we also need compile-time vs. runtime build-depends in our .cabal files,</span><br></blockquote><blockquote type="cite"><span>and so on.</span><br></blockquote><span></span><br><span>Yes, I was just looking into this yesterday. We already have something</span><br><span>similar for plugins, though of course the TH story is much more</span><br><span>involved (in part because GHC has to compile haskell code, not just load</span><br><span>and run a pre-existing object file).</span><br><span></span><br><blockquote type="cite"><span>Its a big project, but ultimately we do have to tackle it, because it's the</span><br></blockquote><blockquote type="cite"><span>right thing to do. Anyone interested in working on this? Maybe start a</span><br></blockquote><blockquote type="cite"><span>new proposal to flesh out the details.</span><br></blockquote><span></span><br><span>Yeah, I'm going to at least try. Don't know where formal proposals go,</span><br><span>but what I've got so far (definitely subject to change!):</span><br><span></span><br><span>1. Add a separate package database like we have for plugins for TH</span><br><span> imports, defaulting to the normal package database when empty</span><br><span>2. Use the TH package db for code to be *run*, but resolve all</span><br><span> reifications etc. against the normal target scope.</span><br><span>3. Add {-# TH #-}-annotated imports to specify modules to import</span><br><span> compile-time code from (if a module *also* has definitions to be</span><br><span> reified, it needs to be imported twice)</span><br><span> 3a. If a module has any {-# TH #-} imports, enforce that *all*</span><br><span> compile-time executed code is pulled in via {-# TH #-} imports.</span><br><span> 3b. Optionally add a warning for TH-using code that doesn't use</span><br><span> {-# TH #-}, as the first start of a migration path to enforcing</span><br><span> compiletime/runtime separation across the ecosystem.</span><br><span> 3c. Not sure what the specific difficulties are that require the</span><br><span> staging restrictions, but possibly annotating same-module</span><br><span> definitions with {-# TH -} might make this easier?</span><br><span>4. Teach cabal how to add packages to the TH database</span><br><span> 4a. Not sure how all this works, but probably this is the place to</span><br><span> e.g. request the non-profiled version of a package if ghc is</span><br><span> non-profiled and the target code is profiled</span><br><span>5. Modify the build process of the cross-compiler to build a stage-2</span><br><span> compiler that builds code for the target *and* host (at least, enough</span><br><span> of the host to build BCOs), and runs that host-targeted code in the</span><br><span> interpreter.</span><br><span> 5a. This will require some way to distinguish</span><br><span> stage-2-as-target-native-compiler VS stage-2-as-hybrid-compiler.</span><br></div></blockquote></body></html>