The evolution of GHC

#101

Me:

So no splitting […]

o_O …it was - in which thread?

Is there (yet!) another Discourse thread somewhere, about this topic, that I’ve failed to notice? It could have saved all of us going on this long, winding trip back to nowhere:

#102

Yes it might not be so obvious form the headings, but the idea is that the first “cleave in two” might not really cutting along the right “plane”, and then we move things across the boundary after.

“cleaving” is a fun dramatic word, but it’s kinda the wrong metaphor, come to think of it. Really, it’s more like pulling two sides a part, and letting it rip “just happen” wherever the bonds are weakest. “Rip base in two” would be better, as paper rips are expected to by messy and not necessarily along the path desired a priori.

The evolution of: Decoupling base and GHC
#103

If it was just a matter of “cleaving splitting tearing slicing cutting dividing chopping ripping up base into two or more pieces”:

  • It should have been attempted at least once by now;
  • It would have been easier to do back when base was smaller e.g. back in 2010.

It seems to me that the simplest option is to just move the morass of code in base to a package more ghc-centric, then starting afresh, either in an empty base or an all-new package under a different name. This approach provides the luxury of ignorance: you can just start writing new code almost immediately instead of trying to pick a path of least resistance.

#104

If you’d wanted all along to talk only about base libs, your topic title should say so. “The evolution of GHC” seems like it’s throwing in the kitchen sink. I only got involved after the discussion moved to FP in-general and history of Haskell in-general.

I suggest you start a new topic with a carefully circumscribed title. This one has gotten beyond useful.

#105

I had to come up with a title when splitting off this thread. I based the current title of the quotes in the first post which discuss the speed at which GHC should evolve. I don’t know if @atravers can actually change it.

#106

@atravers yes, base reexports ghc-base, and we move over to base proper just what is convenient.

The only difference is I think @Kleidukos’s heuristic of "just non - GHC.* modules is a better first shot at doing the rip, and I emphasize moving code not coppying code.

All that, though, just reflects on the first few hours of the attempt :). After that, I think it’s exactly the same.

#107

…better yet: since we’re back on this topic again, instead of trying to find consensus on how to balance stability with evolution in Haskell (and therefore, for the moment, GHC), let’s now all head back to “Pre-Pre-HFTP: Decoupling base and GHC”.

See you there!

#108

The irony is this conversation was split out from the split the libs discussion! Because it went off the rails!

People need to vent. That’s fine with me. Now I’m just trying to steer the energy back to “only modularity and the flexibility it creates” will save us.

I think that’s even in your interests, @AntC2. If we can’t afford multiple GHC-sized implementations, and we can’t agree on language directions, we should have amazing libraries so GHC can be easily “remixed” for all many of research prototypes.

3 Likes
#109

The evolution of: Decoupling base and GHC - #13 by sclv :

there was a long argument on haskell’s popularity [here]

…yes there was: I was offline at the time when it happened, and missed (or forgot about) it while I was skimming over the resulting backlog - thank you, @sclv.