How should we treat changes to the GHC API?

[John Ericson]

On 7/27/20 10:57 PM, Richard Eisenberg wrote:
> I guess I'm arguing that ghc-lib (or something like it) should be the 
> permanent solution. GHC will always be in flux internally.

So to be clear I don't disagree that GHC will always be in flux. But I 
think things like ghc-lib largely work today because GHC is so imperative.

Once it (hopefully!) is more functional, we'll have the problem less 
that functions change[1], and more that data structures change. I think 
that will be harder to abstract over---often to migrate an interface 
properly, data structure will need migrations in both directions *and* 
that those migrations form an isomorphism, which can be an impossible 
requirement. It's just a fact of life that rich data structures make 
migrations harder, but that's no reason we shouldn't have rich data 
structures!

I'm probably too deeply exploring what's only one possible future at 
this point, so let me rewind out of that exact hypothesis and just make 
the broader point that if the interfaces change a lot, a lot of 
organizational stuff can/should too. If the interface changes *don't* 
engender cultural shifts around working with GHC, we're probably doing 
them wrong and they are vapid churn after all!

John

[1]: there should be way fewer functions than today. we currently have a 
gratuitous combinatorial explosion of little helpers which obscures what 
the underlying orthogonal concepts are.