Expose unit ID in info table provenance information

[bgamari]

Currently GHC.InfoProv.InfoProv exposes module names but not the unit ID where the module lives. I propose that we fill this gap by adding the following field to InfoProv:

ipUnitId :: InfoProv -> String

Providing this information without significantly increasing the binary size overhead of IPE information requires some refactoring of the whereFrom# primop, which is currently exposed by GHC.Exts. As this primop is not intended for use by end-users, I propose that we remove it from GHC.Exts as nearly all users can instead rely on the safer and more stable GHC.InfoProv.whereFrom.

Implementation: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11341

[bgamari]

Is there anything I can do to help move this along?

[hasufell]

Since this is GHC internals, +1 from me

[mpickering]

Anything that can be done to move this one forward?

[Bodigrim]

I propose that we remove it from GHC.Exts as nearly all users can instead rely on the safer and more stable GHC.InfoProv.whereFrom.

@bgamari is this implemented in the MR? I do not see any restriction of imports from GHC.Exts.

But anyway +1 from me, whereFrom# is unused outside of ghc itself.

@tomjaguarpaw @velveteer @mixphix @angerman @parsonsmatt any more opinions?

[Bodigrim]

@bgamari @mpickering just a reminder about my question above. Clarifying it would help to move the proposal forward.

[mixphix]

I have no issue with removing this primop. +1

[bgamari]

@bgamari is this implemented in the MR? I do not see any restriction of imports from GHC.Exts.

I have rebased the MR and implemented the import restriction.

[bgamari]

It would be great to be able to move this forward.

[Bodigrim]

There is quite a lot going on in the MR, but I imagine it would mostly fall outside of the interests of CLC members. There are two visible changes:

• The record GHC.InfoProv.InfoProv is extended with a new field ipUnitId :: String. This is, strictly speaking, a breaking change.
• GHC.Exts.whereFrom# is no longer exported, clients are supposed to use GHC.InfoProv.whereFrom. This is also a breaking change.

I seriously doubt that these breaking changes will affect anyone. I'm fine with voting in favor of the proposal, but I'm not sure other CLC members will share this opinion. If there is an interest to proceed with breaking changes the procedure requires an impact assessment.

We can make the change non-breaking:

• Provide a pattern-synonym retaining the old structure of InfoProv.
• Do not remove GHC.Exts.whereFrom# just yet, attach a deprecation warning for now.

@angerman @tomjaguarpaw @hasufell @mixphix @velveteer @parsonsmatt opinions?

[tomjaguarpaw]

Personally I'm fine with making this change without any deprecation period. I suspect only experts will be using these features, and they will have very specialised use cases. I'm confident they'll be able to deal with any breakage that arises.

That said, I'd ultimately love this functionality to be migrated out of base and into a package maintained by GHC HQ. It is GHC-specific and it seems like an unnecessary drag to have this tied to base (and therefore to GHC releases) and to have it subject to CLC approval.

[TeofilC]

FWIW I've created a wherefrom-compat package to export a stable interface for this stuff given that there have already been quite a few breaking changes in previous releases, and to ease migration for my proposal that touches similar code (if it gets accepted) but also ones like this one

[simonpj]

That said, I'd ultimately love this functionality to be migrated out of base and into a package maintained by GHC HQ. It is GHC-specific and it seems like an unnecessary drag to have this tied to base (and therefore to GHC releases) and to have it subject to CLC approval.

Does it need to be "ultimately"? The CLC could say, today, "please put all this in ghc-experimental, but expose the following smaller, stabler, but less expressive API from base". Why wait?

[tomjaguarpaw]

Does it need to be "ultimately"

Indeed not, I'd love for it to happen as soon as it can. I don't have the spare cycles to push for that myself though.

The CLC could say, today, "please put all this in ghc-experimental

I've been saying that with varying degrees of success¹². Personally I would love this deeply-GHC-coupled stuff to be out of base. I don't have the time or energy to oversee its removal, let alone the work required to provide a smooth transition, but I can at least keep an eye out to ensure things don't get significantly worse.

but expose the following smaller, stabler, but less expressive API from base

In general that seems like the right approach, but in this specific case I'm not convinced any form of "table provenance information" belongs in base. I don't even know what it is! It sounds like something that is only relevant to people doing deeply magical things with the compiler, not everyday Haskell programmers. Please correct me if I'm wrong.

Footnotes

1. https://github.com/haskell/core-libraries-committee/issues/230#issuecomment-1831976429 ↩

2. https://github.com/haskell/core-libraries-committee/issues/209#issuecomment-1729920377 ↩

[bgamari]

Has there been a final decision on this?

[Bodigrim]

Does it need to be "ultimately"? The CLC could say, today, "please put all this in ghc-experimental, but expose the following smaller, stabler, but less expressive API from base". Why wait?

We are half a year past "split base" proposal, which several GHC developers were extremely eager to push --force for, yet nothing has changed in GHC HEAD. Because it proved easier to say (and advocate for) than do.

I was deliberately slow with processing several CLC proposals here in a false hope to see some resolution to ghc-internal / ghc-experimental split so that we can suggest "please put all this in ghc-experimental" in good faith. This proved to be a bad decision.

We should not assume that ghc-experimental is happening until it happens for real. End of digression.

---

Has there been a final decision on this?

I'd like to hear non-binding opinions of other CLC members if they are happy to vote in favor of the proposed breaking changes. You can trigger a binding vote immediately though, if you wish so.