How should we treat changes to the GHC API?

[John Cotton Ericson]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200731/94adfba5/attachment.html>