#3843: Merge plugins into HEAD ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: 7.0.2 Component: Compiler | Version: 6.13 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------
Comment(by thoughtpolice): Hi shelarcy (sorry for the delay in reply!,) I think Supercompilation seems ''possible'' from a plugin perspective. From what I can tell, Simon has implemented a flag called `-fexpose-all- unfoldings` in GHC which will put all unfoldings for everything in interface files - this is great for whole program work of any sorts or supercompilation, like the work Neil or Max & Simon are doing. I haven't looked at the implementation of expose-all-unfoldings myself however. Simon, can you comment on the possibility of utilizing expose- all-unfoldings from `CoreM`? It seems as though `ModGuts` exposes most of the necessary dependency information for the currently compiled module, to find what's needed for something like this, meaning we *could* use a `ModGutsToBindsPluginPass` (or, if we're daring, a `ModGutsToModGutsPluginPass`.) I don't know if this is enough, however (I do not have enough GHC-fu.) As for the static contract checking work, I honestly have no idea. I have not read Dana's paper, but from the abstract it seems it works by symbolic execution with the contracts in mind - I don't think this happens at the Core level however from a quick glance, and currently that is all the plugin work encompasses. It does not expose all the internal phases of GHC - only a limited API allowing us to analyze/rewrite core bindings at the moment. I think this is outside of the scope of the actual plugins work, but I could be wrong (again, Simon should say something here because I could be completely wrong.) Finally, as for the Cabal concern, I think you may be right, but my intuition tells me that as a client, you would only depend on the actual datatype definition for the annotation, and not any code which *directly* touches the GHC package itself. I would expect that the linker would remove the GHC package as dead code during the final link step. I have not tested this myself, but I should in any case. Thanks for pointing this out, I'll get back to you when I get the chance. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3843#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs