Develop better handling of “wired-in” items

[mpickering]

When moving code from ghc-internal to base (see #1), an important questions is what to do about so-called wired-in items, like primitive operations or types and operations needed for desugaring. Currently, GHC requires such items to be implemented in ghc-internal, but those items that are only needed for desugaring may be better placed in base.

It seems that we need to change the way GHC handles “wired-in” items. We may get good ideas for this by looking at Agda and Rust, which allow for declaring that certain defined items are to be used as certain wired-in items.

[Ericson2314]

I think the question of "wired-in" is good to break in half, and look at in two direction:

1. Sometimes GHC defines some magic that libraries use, Int# or (->) would be good examples.
2. Sometimes libraries define something normal that GHC needs to use, Monad or List would be good examples.

Currently the GHC treats these both as the same thing, and uses "wired-in" for both. The current design I think is fine for (1) --- we can just pick a location in ghc-internal and stick to it, and since GHC versions and ghc-internal versions are 1-1, this is fine. But the current design is not appropriate for (2), because these are the types of definitions we would like to move back out of ghc-internal and back into base per issue #1.

[jeltsch]

I must say that I’m not quite following the description of this issue. From what I understand, the quotations by @angerman and @Ericson2314 are about what ghc-internal provides for base. However, the surrounding explanatory text talks about ghc-internal, base, and some unspecified packages providing something to the compiler.

[jeltsch]

Furthermore, the first paragraph abruptly ends after an “and”. Is the text of the following paragraph (“Moritz and John have expressed this viewpoint already”) supposed to belong to the same sentence, or has something accidentally been deleted here?

[jeltsch]

I realized that the topics of #1 and #2 (this issue) overlapped and were partly quite broad. Therefore, I modified the two issues a bit such that #1 is now only about the interfaces and contents of base and internal libraries, while #2 is about “wired-in” items.

[simonpj]

Here's a copy-paste of haskell/core-libraries-committee#375 (comment)

There is a brief description of what GHC does about wired-in entites and known-key entities here: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/wired-in

I think this ticket is talking not about wired-in entities but rather known-key entities, which are far more numerous. I strongly urge us to use the same terminology as GHC does, or we'll get endlessly confused.

It would be hard to change the way that wired-in entities work, but that doesn't matter much becuase they are few.

For a known-key entity E the current arrangement is that

• GHC must know the precise module, say M, in which it is defined.

That way GHC can go to that M.hi file and read in the details of E.

But it would not be difficult to change it so tha the rule was:

• GHC must know a module, say M, that exports E

Now it can go to M.hi, and find out from there where E is defined.

For example for map rather than knowing which module actually defines map, GHC could go to base:Prelude (which should export map) and find out where it's defined. Similarly for Arrow, GHC could go to (say) base:Control.Arrow to find where the Arrow class is actually defined.

It's clearly essential that GHC has some way to find the definition, but this change would dramatically loosen up the constraints, in the way that John describes.

[Ericson2314]

I have created https://gitlab.haskell.org/ghc/ghc/-/issues/26657 with the same copy-paste for the first part of the problem. I have also created https://gitlab.haskell.org/ghc/ghc/-/issues/26658 because known-key reexports fixes one problem just to reveal another, and thus must also be fixed.

https://gitlab.haskell.org/ghc/ghc/-/issues/26658 has two strategies to fix, a cheaper/worse-UX ones, and a more expensive/nicer-UX one. I am fine with either, but my preferred approach is to quickly do the cheaper one to unblock reinstallable base work by library maintainers, and then work on the more expensive one in parallel to that, while no one is blocked.

[Ericson2314]

I also made https://gitlab.haskell.org/ghc/ghc/-/issues/26659 for actually wired-in definitions, but to be clear, I fully support ignoring that issue until the previous two are figured out. I am just writing it down now to "page it out of my head" and save it for later.

[simonpj]

I believe you are talking about known-key things, not wired-in things. Easy to confuse, but it would be good to be sure we are on the same page https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/wired-in

[Ericson2314]

See what I wrote in https://gitlab.haskell.org/ghc/ghc/-/issues/26659#note_647754 . My intent was to get my nomenclature right: https://gitlab.haskell.org/ghc/ghc/-/issues/26657 and https://gitlab.haskell.org/ghc/ghc/-/issues/26658 are about known-key definitions. Only https://gitlab.haskell.org/ghc/ghc/-/issues/26659 is about wired-in definitions, and my intention is that we can ignore that issue for now.

(In https://gitlab.haskell.org/ghc/ghc/-/issues/26658 I say wired-in-unit just because that was the verbatim name of the GHC note --- I gather that known-key definitions use wired-in unit ids.)