Making (useful subsets of) bytecode portable between targets

[Moritz Angermann]

There is https://github.com/ghc-proposals/ghc-proposals

Sent from my iPhone

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