On 7/31/20 9:27 AM, Simon Peyton Jones via ghc-devs wrote:
My real question is this:
* Who “owns” (as in: takes responsibility for) the GHC API?
I guess one thing very important to me is that the architecture of GHC
and it's public interfaces will always be deeply intertwined; or put a
different way, efforts to manager the public interface as a thin veneer
over a big black box will not work.
* What *is* a good public API? Where is it written down?
This I agree is important to discuss. I do agree with Moritz that a lot
of this stuff can be evolved, but the general direction can be still be
discussed. For example, the basic objects I offered are a *huge*
departure from what we have today, and any huge change should be
discussed up front a bit.
* 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.
* What is a good design for the plugins story more generally?
I've mentioned this before but I think plugins/hooks/etc. are a terrible
way to reuse GHC for other purposes, and exist as a symptom of the rest
of the compiler not being at all modular. It's fine that we continue to
support them in the short term, but in the long term I'd really like to
have a plan to obviate them completely. (One can search "composition
over configuration" and variations on that slogan to find much ink has
been spilled on this general principle.)
John
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
