#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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
