I think it sounds like a potentially good idea in general, but I agree with
Ben and Matthew here that a more concrete plan of intended use is needed.
Adding "pluggable backends" to spin up new targets seems to require quite a
bit of additional infrastructure for initialising a library directory and
package database. But there are probably more specific use cases that need
inspecting/modifying STG or Cmm where plugins would already be useful in
practice.
Hooks (or rather their locations in the pipeline) are rather ad hoc by
nature, but for Asterius a hook that takes Cmm and takes over from there
seems like a reasonable approach given the current state of things. I think
the Cmm hook you implemented (or something similar) would be perfectly
acceptable to use for now.
I don't think it's a problem if a hook exists for some time, and at some
point it's superseded by a more general plugin mechanism. Especially with
the GHC 6 month release cycle there's not much need for future proofing.
Luite
On Thu, Oct 4, 2018 at 3:56 PM Shao, Cheng
Hi all,
I'm thinking of adding "backend plugins" in the current Plugins mechanism which allows one to inspect/modify the IRs post simplifier pass (STG/Cmm), similar to the recently added source plugins for HsSyn IRs. This can be useful for anyone creating a custom GHC backend to target an experimental platform (e.g. the Asterius compiler which targets WebAssembly), and previously in order to retrieve those IRs from the regular pipeline, we need to use Hooks which is somewhat hacky.
Does this sound a good idea to you? If so, I can open a trac ticket and a Phab diff for this feature.
Best, Shao Cheng _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs