# Pre-Pre-HFTP: Decoupling base and GHC

**URL:** <https://discourse.haskell.org/t/pre-pre-hftp-decoupling-base-and-ghc/3727>\
**Category:** Uncategorized\
**Created:** [November 25, 2021, 8:00am UTC](https://discourse.haskell.org/t/pre-pre-hftp-decoupling-base-and-ghc/3727 "2021-11-25T08:00:07Z")\
**Posts on this page:** 1\
**Showing post:** 38

<div class="post-metadata">

**Author:** ![simonpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonpj/32/890_2.png) [@simonpj](https://discourse.haskell.org/u/simonpj)\
**Post date:** [February 2, 2022, 2:19pm UTC](https://discourse.haskell.org/t/pre-pre-hftp-decoupling-base-and-ghc/3727/38 "2022-02-02T14:19:10Z")

</div>

> [@ketzacoatl](#):
>
> What’s fuzzy about this and what could be done to sharpen the definition here?

The fuzziness is this: what is a sharp criterion that tells you whether a type or function belongs in the “GHC-specific” part or the “pure library” part?

One possiblity is this. Consider an entity E, where “entity” means type, data constructor, class, or function.

- If GHC has specific knowlege of E, then E is GHC-specific. In GHC-jargon, these are the “wired-in” things and the “known-key” things.
- If a GHC-specific entity E’ depends on E, then E is also GHC-specific.
- Everything else is pure-library

I’m not sure if that’s enough, but it’s a start

---

_[View the full topic](https://discourse.haskell.org/t/pre-pre-hftp-decoupling-base-and-ghc/3727)._