Hide GHC.TypeLits.Internal and GHC.TypeNats.Internal

[phadej]

The GHC.TypeLits.Internal and GHC.TypeNats.Internal exist so some module cycles can be broken in base. They don't export anything GHC.TypeLits or GHC.TypeNats doesn't.

Nothing on Hackage uses these, https://hackage-search.serokell.io/?q=GHC%5C.Type%28Lits%7CNats%29%5C.Internal

This is small cleanup.

MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10596

[phadej]

@Bodigrim I'd like to trigger a vote

[tomjaguarpaw]

To be clear, does this proposal hide a module (i.e. remove it, as far as any consumer is concerned) without any indication that this removal is going to happen in the current Haddocks, nor any indication of what a consumer should do to fix their code?

(I appreciate that there may well be no consumers.)

[phadej]

without any indication

Yes.

(I appreciate that there may well be no consumers.)

As I mentioned in the description, there are no consumers on Hackage.

[tomjaguarpaw]

(I appreciate that there may well be no consumers.)

As I mentioned in the description, there are no consumers on Hackage.

Perhaps a miscommunication on my part. I meant "I acknowledge that there are no consumers but I am asking nonetheless."

Perhaps other CLC members will disagree with me but I think that we should make an effort to take stability and smooth migration seriously and even though it's unlikely that unexposing this particular module will break anyone I think it's a good idea to get into the habit of providing a smooth upgrade path. Here I would suggest at least one base release (even a minor one) with a clear notice at the top of this module's Haddock indicating that it should not be used and saying what the alternative is.

[mixphix]

Here I would suggest at least one base release (even a minor one) with a clear notice at the top of this module's Haddock indicating that it should not be used and saying what the alternative is.

I agree, only if there has been at least one released version of base with these modules exposed.

Since they were exposed two years ago, despite having no consumers, we ought to follow a deprecation cycle.

[phadej]

I won't track deprecation cycle. If CLC would take ownership of that (in particular remember to actually remove them), I welcome that. Otherwise, I don't really mind those modules staying exposed indefinitely.

[adamgundry]

Thanks @phadej for proposing this, I think it's a good idea.

@tomjaguarpaw

Perhaps other CLC members will disagree with me but I think that we should make an effort to take stability and smooth migration seriously and even though it's unlikely that unexposing this particular module will break anyone I think it's a good idea to get into the habit of providing a smooth upgrade path. Here I would suggest at least one base release (even a minor one) with a clear notice at the top of this module's Haddock indicating that it should not be used and saying what the alternative is.

I think there is a tension here. Stability is important, but if we take it to the extreme we risk stasis. Does the effort required to give (hypothetical) consumers warning of the module's removal really justify the cost in this case? Of course it's up to the CLC to make this call, but discouraging volunteers such as @phadej from helping clean up the base API might be worse than inconveniencing consumers of these modules (if there are any).

[hasufell]

I think a deprecation cycle (1 major release) for this is not controversial and not a lot of work.

[phadej]

and not a lot of work.

It's a work spread out in time.

I won't be there for actually removing the module in 9.10, if it's first deprecated in GHC-9.8.

[tomjaguarpaw]

If CLC would take ownership

I'll personally take ownership. First required step (i.e. changing the Haddocks to warn not to use) implemented at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10653. I would appreciate a review.

I think there is a tension here.

Yes, definitely. Stability and change both bring benefits and it's hard to walk an optimal path. Nonetheless, I'm convinced that providing smooth deprecation cycles is the correct thing to do. (I'm also convinced that the Haskell community has leant far too hard towards the "change" end during its existence.) I'm not particularly worried that efforts towards stability will be a net negative in terms of contributors. In my view increased stability in the Haskell ecosystem will be a massive boon in terms of incoming contributions.

[hasufell]

I can only speak for myself, but I think that making decisions based on whether they cause a contributor to disengage or not is the wrong way to go about it.

And yet, we want contributors to be engaged and have a good experience. But, IMO, the way to do that is to be responsive, have good documentation and be clear about requirements and expectations.

[tomjaguarpaw]

Regardless of the decision the CLC takes on this I'm grateful to @phadej for bringing this to our attention. I probably wouldn't even have realised the existence of these modules otherwise.

[mixphix]

Thank you @phadej for the proposal and @tomjaguarpaw for the MR.

---

As for "work spread out in time", as Oleg puts it, I think it would be beneficial to have a set of "review" tags for CLC proposals, to go through when a new version of base becomes available and deprecation cycles progress. It's one thing to deprecate a bit of code, with the intention of removing it later; but if it never gets removed, then what was the purpose of deprecating it? I recall the Option type from Data.Semigroup whose documentation stated that it would be removed in 8.10, but was not actually removed until 9.0 (in base-4.15). IMO, having had a "completed" proposal with a "review at GHC X.Y" label would make these changes less likely to go unnoticed, as it also allows community members to pay attention in case the CLC does miss something.

[phadej]

disengage or not is the wrong way to go about it.

I have to say this publicly: recently I had to weight very carefully whether I want to make a proposal or even open an issue relating base. And this experience makes me weight it even more. The process is just too heavy. I'm quite convinced that no changes to base are worth the effort.

[phadej]

@mixphix

In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10653 the module is not even deprecated. Solely a documentation change. I'm sure no-one will ever notice it. It also currently says "may be removed in the future", i.e. it may not ever be removed.

The current stance is too extreme. I really don't see how base could evolve without burning out most people trying to do anything.

On the other hand, foldl' is just added to Prelude. Breaks plenty of code. No warnings beforehand. Yet, no library maintainer really opposes that AFAICT.

[mixphix]

Did you see the number of pull requests @Bodigrim opened just to push that one function through? Yes, it is hard work to change base, as it should be. If you do not care strongly enough about doing this work to effectuate the changes you want to see, then simply do not bother proposing the change in the first place.

[tomjaguarpaw]

the module is not even deprecated. Solely a documentation change

This is a fair point. I'm not sure what the consequences of deprecating those modules would be, specifically, would it cause a build error when they're imported by GHC.TypeNats/Lits (which is a valid place for it to be imported)? I don't know and I don't have the bandwidth to determine the answer right now.

[phadej]

@mixphix

Did you see the number of pull requests @Bodigrim opened just to push that one function through? Yes, it is hard work to change base, as it should be.

I did. And that is welcome. But this change doesn't break anyone on whole Hackage (not just Stackage). You make easy things hard. If it makes you happy, so be it. It doesn't make me happy at all.

And for the record. I wouldn't minded foldl' addition to Prelude without patches either. The libraries which I maintain (which would break without a patch), the problem was waiting to happen anyway, they were written poorly assuming Prelude would never grow or change (this might been true, but not true for a while).

In fact I think @Bodigrim sets a dangerous precedence, can I assume there will be not only patches but pull requests for all breaking changes in base? That would nice, I guess, but the bar for change in base is keep raising. And as I said, it has risen too high for me to want to change anything.

[chshersh]

But this change doesn't break anyone on whole Hackage (not just Stackage)

You can never assess what people use in their private Haskell projects (e.g. in the industry). So CLC must work under the assumption that any breaking change can, in fact, break something.

[mixphix]

I wouldn't minded foldl' addition to Prelude without patches either

It's abundantly clear that you speak only for yourself. Had it not been for the expediency with which Andrew gracefully submitted patches to all of the (public) affected libraries, I expect there would have been a great deal more fuss about the change than was already made in that ticket.

In fact I think @Bodigrim sets a dangerous precedence

The only thing "dangerous" here is that you expect to continue to expend the minimum amount of effort in restructuring the single most critical library in the entire Haskell ecosystem with absolutely no repercussions or expectations about future maintenance.

You make easy things hard

Trust me, I know.

[Bodigrim]

What if we a) mark GHC.Type{Li,Na}ts.Internal as deprecated in GHC 9.4.6 and 9.6.3, b) remove the modules completely in GHC 9.8 and newer? Would it be a sufficient migration window, given that the modules are entirely unused on Hackage?

[tomjaguarpaw]

That would be fine by me @Bodigrim. Given that these modules appear to be unused what I want is that there is at least some documentation in a relevant place to leave breadcrumbs in the unlikely event that someone gets hit by this.

[mixphix]

I think omitting the deprecation pragma is fine in this case due to these modules’ special situation: they are not to be removed, simply unexposed, since they still serve the purpose of eliminating cycles. That said, I agree with the need for a strong recommendation to use other modules, so that any current consumer we may not anticipate is aware they are shooting themselves in the foot.

[Bodigrim]

Any more opinions on lightweight deprecation schedule suggested in https://github.com/haskell/core-libraries-committee/issues/171#issuecomment-1590226719? A good property of this schedule is that the work is not spread out in time: all MRs can be created and merged at once. And yet it provides heads-up to users.

@chshersh @hasufell @parsonsmatt @angerman

[hasufell]

+1 to lightweight deprecation cycle

[chshersh]

Sound good to me as well 👍🏻

[angerman]

+1, Sounds reasonable. I'm also curious and I do want to see this play our as well.

Just one side note, that I feel is often completely ignored when talking about breaking changes. It's not only about the patches to libraries that are require. It's also about the ripple effect this creates. And that is often even worse. I can patch 10 packages in a day. But dealing with the resulting bumps (including major bumps because only the latest version gets the compatibility), is what cause major cascading breakage down the line.

Assume you are for some reason depend on text-1, however text development has moved on to text-2, to use a newer compiler, you now also have to upgrade to text-2, and deal with that cascading though your codebase. And the larger your codebase is and the more packages you use the worse this becomes.

One solution is to move everything in-house, ignore upstream and just keep patching old versions as needed; which which gives full control but also means you are now maintaining everything yourself. I'd rather we contribute collective, but that becomes virtually impossible if you end up finding yourself on end of life branches.

[Bodigrim]

@phadej are you happy for us to vote on https://github.com/haskell/core-libraries-committee/issues/171#issuecomment-1590226719?

[phadej]

@Bodigrim No, I'm not happy. @tomjaguarpaw took over with https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10653, which is already merged MR, so I don't think there is anything to do with this proposal. They should follow up.

EDIT: In particular, decide first, do then. Now you have already done (something).

[hasufell]

@tomjaguarpaw took over with https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10653, which is already merged

That's technically a documentation change only and doesn't require a vote.