Hello Alan, SPJ and I both think that GhcMake is well overdue for a rewrite. But it's not altogether obvious what the rewrite should look like. I've made some remarks here: https://gist.github.com/ezyang/50004e0f842eec5848acad5cf1c22240 I'm OK with small, incremental changes that make tooling's life better. But adding renamed/typechecked ASTs is almost certainly the wrong thing to do. The ModSummary is produced by looking at an hs file and doing the bare minimum processing to get the import graph. The way the pipeline works is a ModSummary is eventually turned into a HomeModInfo by the typechecking process. So one possibility is that if it is requested (retaining renamed, typechecked ASTs increases memory consumption for clients that don't need it) the things you want could be stashed in HomeModInfo. So you'd probably augment FrontendResult to return the information you need, and then hscIncrementalCompile to stick it in HomeModInfo. Things to be careful about: - You will NOT get this info if you load the HomeModInfo from disk rather than compile it directly. I am assuming that you have a way to convince 'load' to rebuild; I don't actually know how to do this. - We don't want to save this info by default; it will increase memory usage for anyone who doesn't need it (e.g., ghc --make) Hope that helps, Edward Excerpts from Alan & Kim Zimmerman's message of 2016-09-05 20:27:26 +0200:
At the moment the standard way to use the GHC API is something like
_ <- load LoadAllTargets modSum <- getModSummary mn p <- parseModule modSum
And likewise if renamed or typechecked ASTs are needed.
But the `load` step already does all those phases.
So, would there be any objection to modifying the ModSummary to possibly retain those artifacts, configurable via a DynFlag?
I would expect the flag would default to retaining none, but could then either provide for returning all artifacts, or just for the targets explicitly listed in the `setTargets` call (i.e. not the full `depanal` result).
Regards Alan