I think this is the core issue here: > What should GHC’s extensibility interface be like? Plugins and all that. > What is a good design for (say) extensible interface files? What “hooks” > should the GHC API afford? This is more than just “what arguments should > this function take”… it’s a matter of fundamental design. But design > questions like this belong in the GHC-API world (not the core GHC world) > because they are all about extension points. I don't think we know this apriori, and it will be discovered over time as more and more producers and consumers start making use of it. Is the current design the best one? I have my doubts, is it a first approximation? I think so.
I think these features are more discovered than designed. It's easier to iterate over concrete implementations in this area than over abstract ideas. I would propose having some EXPERIMENTAL markers for these kinds of features. I do agree that a group of people who feel strongly about this should be listed in the CODEOWNERS file for the respective parts of the codebase, and take an active part in code review. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs