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.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
