Move GHC.RTS.Flags out of base.

[doyougnu]

What

Presently, we expose GHC.RTS.Flags in base. This proposal proposes to move them out of base and into ghc-internal or some other similar package. We can decide where would be best in the comments.

Why

It is non-obvious that have GHC.RTS.Flags in base creates downstream issues, but in practice this is the case and we end up creating more work for the CLC, for GHC developers, increase coupling of base to GHC versions. There are several CLC proposals which were only created because these flags are exposed in base, and as far as I can tell there isn't much debate in any of the proposals:

• Add --optimistic-linking to GHC RTS Flags exposed in base. #288: adds a RTS linker flag, which becomes exposed in base, and therefore requires a CLC proposal
• Minor tweaks to GHC RTS flags exposed via base #263: created in response to @dcoutts work on the RTS IO managers. This modified the RTS flags in response to the new manager thereby requiring a CLC proposal.
• Add new RTS options introduced by eras profiling to GHC.RTS.Flags  #254: added new RTS flags for profiling modes
• Expose --no-automatic-time-samples in GHC.RTS.Flags API #243: similar to Add new RTS options introduced by eras profiling to GHC.RTS.Flags  #254

Which begs the question: Is there a meaningful debate to be had for RTS flag changes like this? And should that debate occur in base with the CLC. So far these seem to have been relatively uncontroversial.

Implementation

I will implement and this should miss the 9.12 fork. I'm unsure if ghc-internal is the best home for these flags. I'll bring this up in the next GHC call. But I think it is the best place we have right now.

The plan is given by this comment. To be succinct we:

1. create compat functions and types in base. This is MR!13428 and is implemented, waiting on review.
2. move the flags to ghc-experimental and expose them through ghc-experimental. This is where consumers should expect to use these flags moving forward. This is MR!13343, it still needs work but should be trivial I just won't have time until this Friday.
3. Begin deprecating by adding warnings to the compat functions and types from (1). Not yet done.

Impact

As Duncan writes in #263:

The GHC RTS flags are currently exposed via base in GHC.RTS.Flags. The types there reflect 1:1 the GHC RTS CLI flags. Thus these types are obviously tightly coupled to GHC and the GHC version.

This is exactly right, and so decoupling these flags is a meaningful step towards the ghc-base split.

[hasufell]

Does anyone feel this needs a deprecation period?

[mixphix]

I think that because the API is kept in such a close tandem with the compiler that we should be able to get away without a deprecation period, provided that we find a new home for the module where it remains up-to-date with the compiler as current. I suggested ghc-internal in another thread but there may be a more suitable place I'm not aware of. I think in this case telling users to depend on ghc-internal for the compiler flags isn't such an unreasonable request.

[adamgundry]

Thanks for pushing this forward @doyougnu! I agree that RTSFlags should be moved out of base to reduce unnecessary coupling.

Users are strongly discouraged from depending on ghc-internal, so we should expose it somewhere else. To my mind ghc-experimental is the obvious default home for all user-facing but closely-coupled-to-GHC definitions. That said, a new package would also be possible (as @TeofilC suggested in https://gitlab.haskell.org/ghc/ghc/-/issues/25275#note_585663), and could in principle be created with support for existing GHC versions so users could migrate immediately. However it comes with added long-term maintenance burden as it would need to be updated on each GHC release. This is ultimately a decision for the GHC maintainers.

I can see a few plausible migration strategies:

• Simply move GHC.RTS.Flags to a different package in GHC 9.14. This feels like it might break quite a few packages and seems rather aggressive, though the fix is confined to .cabal files.
• Keep GHC.RTS.Flags frozen in base for a few releases (with a deprecation warning); meanwhile add the new module under a different name. This means users have to change their imports to use the new version, but won't be broken as aggressively (or potentially ever, because it seems like the existing API could in principle be maintained indefinitely).
• Re-export the same GHC.RTS.Flags module from both base and the new home for a while, before removing it from base, and encourage users to switch. Unfortunately I don't think reexported-modules can have warnings attached (unlike individual definition re-exports), so it's unclear how effectively this will be at avoiding breakage.

[parsonsmatt]

I feel like ghc-experimental is more for things which are in the "gathering feedback from users" phase - ie, "here's some new API, try it out, it's experimental so we want experience reports, subject to change etc." Whereas ghc-internal is for stuff that's not particularly experimental or controversial, just tightly coupled to GHC implementation details.

Ultimately I think it'd be nice to see GHC.RTS.Flags defined in ghc-internal, and a separate package offering a "compatibility shim" in a backwards/forwards compatible design.

Unfortunately I don't think reexported-modules can have warnings attached (unlike individual definition re-exports), so it's unclear how effectively this will be at avoiding breakage.

This seems like a very useful feature to have on the cabal side for any project that wants to extract modules from one library to another - I'll open an issue.

[tomjaguarpaw]

I agree with @parsonsmatt

[adamgundry]

Adding user-facing definitions to ghc-internal seems to be inconsistent with https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/051-ghc-base-libraries.rst#proposal, which says:

We should develop both social and technical mechanisms to discourage people from depending directly on ghc-internal, because if such dependencies become frequent and ossified, it will lead to future pain when the API changes.

Moreover it suggests as a candidate for inclusion in ghc-experimental:

future APIs to access RTS statistics, which are fairly stable and user-exposed, but which are (by design) coupled closely to GHC's runtime and hence may change.

Just because a package queries some information about the RTS, I don't think it should be forced to depend on GHC internals.

[tomjaguarpaw]

Adding user-facing definitions to ghc-internal seems to be inconsistent with ...

Just because a package queries some information about the RTS, I don't think it should be forced to depend on GHC internals.

I agree that users should absolutely not get the module in question from ghc-internal. My suggestion would be that they should get it from the "compatibility shim" module than @parsonsmatt hypothesises. Indirect dependencies on ghc-internal should absolutely be encouraged, assuming the author of the intermediate package has reason to believe she/he can keep the API stable. After all, base re-exports many entities from ghc-internal!

If GHC HQ really thinks that ghc-experimental is the correct place then so be it. That's up to them. That said, I'm surprised to see the "GHC's base libraries" proposal suggesting it. It doesn't fit under "experimental" as I understand the concept.

[Ericson2314]

Agreed with @tomjaguarpaw

IIRC the current plans for template-haskell are also a mix of better reinstallability and compatibility shims. This should be thought about in the same way.

[parsonsmatt]

Yeah, I guess for me -experimental asks the question "What is the experiment?" whereas -internal immediately indicates "these are internal details to a specific GHC." The linked definitions don't agree with my intuition on what those names mean (but that's on me as much as anything else)

[parsonsmatt]

Cabal upstream issue mentioned: haskell/cabal#10384

[doyougnu]

I too agree with @parsonsmatt and @Ericson2314 and think ghc-internal is the right home because these flags are by their nature coupled to specific GHC releases. But that does not mean that these definitions are user facing. Instead the user facing definitions should be a shim that I am more than happy to keep in base. The goal here is to be able to alter the RTS flags without opening a CLC proposal and causing a breakage. I feel that the ghc-internal + shim in base approach reaches this goal. Furthermore, I believe that the ghc-base-libraries proposal covers this case:

Over time, the GHC developers may make CLC proposals to remove types and functions that are currently in the base API, but are in truth part of GHC's implementation, and were originally exposed by historical accident. But these are future proposals. ...

This is one such proposal. It continues:

To expose a new function from ghc-internal requires that any functions on which it depends are also in ghc-internal (not base). So we may need to move code from base to ghc-internal, leaving a shim behind in base. In practice, that may mean that quite a lot of code will move into ghc-internal quite quickly. But that's fine: it is just an implementation matter: provided the modules, exports, and API of base are maintained, it is immaterial to clients (and hence to CLC) exactly how they are maintained.

This seems to be exactly the path forward we're discussing here.

Does anyone feel this needs a deprecation period?

I desperately do not want a deprecation period and I believe that a deprecation period would exacerbate the ecosystem coupling. Instead I prefer a clean break with a new GHC release. We are in a fortunate position because we still have a coupled ghc and base. So we can do the whole migration at once for a single release of ghc+base. As for the impact, the same 23 packages that were previously impacted will be impacted again.

[tomjaguarpaw]

I desperately do not want a deprecation period and I believe that a deprecation period would exacerbate the ecosystem coupling.

I don't think there will be any objection to moving the original source of GHC.Flags to a GHC-internal package, re-exporting it from its existing location. However, isn't your ultimate aim to change the API of that module? If so, then I don't think that performing the move helps you. You'll still need CLC approval to make the change.

If, on the other hand, you get CLC approval to remove the module from base (so you can put it wherever you like) then you will be completely free from CLC approval regarding changing that module in future.

[Ericson2314]

I think the idea is that the old version in base should either be removed right away, or frozen in place as a permanent back-compat hack. Newer user-facing versions should live with in a separate library (analogous to template-haskell).

[hsyl20]

Note that base:GHC.RTS.Flags is already a shim module reexporting stuff from ghc-internal:GHC.Internal.RTS.Flags.

module GHC.RTS.Flags
  ( RtsTime
  , RTSFlags (..)
  , GiveGCStats (..)
  , GCFlags (..)
  , ConcFlags (..)
  , MiscFlags (..)
  , IoManagerFlag (..)
  , DebugFlags (..)
  , DoCostCentres (..)
  , CCFlags (..)
  , DoHeapProfile (..)
  , ProfFlags (..)
  , DoTrace (..)
  , TraceFlags (..)
  , TickyFlags (..)
  , ParFlags (..)
  , HpcFlags (..)
  , {-# DEPRECATED "import GHC.IO.SubSystem (IoSubSystem (..))" #-}
    IoSubSystem (..)
  , getRTSFlags
  , getGCFlags
  , getConcFlags
  , getMiscFlags
  , getDebugFlags
  , getCCFlags
  , getProfFlags
  , getTraceFlags
  , getTickyFlags
  , getParFlags
  , getHpcFlags
  ) where

import GHC.Internal.RTS.Flags
import GHC.Internal.IO.SubSystem (IoSubSystem(..))            

[adamgundry]

I too agree with @parsonsmatt and @Ericson2314 and think ghc-internal is the right home because these flags are by their nature coupled to specific GHC releases. But that does not mean that these definitions are user facing. Instead the user facing definitions should be a shim that I am more than happy to keep in base. The goal here is to be able to alter the RTS flags without opening a CLC proposal and causing a breakage. I feel that the ghc-internal + shim in base approach reaches this goal.

I agree with this (so perhaps we've been talking at cross purposes). The interesting question is where the definitions are exposed to users. Indeed, note that the definitions are already in ghc-internal (specifically GHC.Internal.RTS.Flags) from where they are re-exported by base! So if you want to keep a shim in base that preserves exactly the existing GHC.RTS.Flags API, while extending GHC.Internal.RTS.Flags, that doesn't require CLC approval or any kind of deprecation period. It's just an implementation matter.

But then the question remains as to how users get access to the extended API, and whether base should continue to expose the existing subset for the long term. Certainly it would be possible to put the extended API in a new package, and doing so could allow forwards as well as backwards compatibility, but that would come at increased maintenance cost, so we have to figure out who is going to ensure the package is maintained.

[tomjaguarpaw]

Note that base:GHC.RTS.Flags is already a shim module reexporting stuff from ghc-internal:GHC.Internal.RTS.Flags.

Ah thank you, so my comments have been slightly misguided then! But I still think they should be exported from a package officially maintained by GHC HQ, blessed as the official way of obtaining them. I don't mind what that package is, but it shouldn't be ghc-internal.

[TeofilC]

Certainly it would be possible to put the extended API in a new package, and doing so could allow forwards as well as backwards compatibility, but that would come at increased maintenance cost, so we have to figure out who is going to ensure the package is maintained.

I'd be happy to maintain (or co-maintain!) something like this. There's a few more bits of base that would be good to eventually move into that package as well such as the GHC.Stats interface, etc. I think we could end up with a pretty nice coherent package.

But also it probably wouldn't be too bad to just expose these from ghc-experimental, especially since I think a lot of these interfaces are used pretty rarely by users. And it's probably a bit less work so that's appealing.

[doyougnu]

Let's recap the conversation:

• The goal is to be able to change RTS flags without a concomitant change to base
• The problem is that by their nature these flags are coupled to a ghc version, as Duncan pointed out.
• The status quo is that these flags are exported out of ghc-internal:GHC.Internal.RTS.Flags and then shimmed in base, as @hsyl20 pointed out. Thanks Sylvain!

Candidate targets:

• ghc-internal this no longer makes sense because these flags are already exported out of ghc-internal. But the other problem with this idea is that it makes it too easy for users to depend on ghc-internal when instead they should be depending on indirect dependencies, hence the shim. Essentially this strategy would conflict with section 6.1 of the aforementioned accepted proposal. Therefore, we can exclude ghc-internal as a candidate and conclude that whatever target we choose it should be considered user facing with a re-export from ghc-internal.

• ghc-experimental does not make sense per the proposal. The proposal writes:

ghc-experimental, initially empty, depends on base and on ghc-internal. Functions and data types here are intended to have their ultimate home in base, but while they are settling down they are subject to much weaker stability guarantees. Generally, new functions and types introduced in GHC Proposals would start their life here. Example: new type families and type constructors for tuples, ghc-proposals/ghc-proposals#475.

But the flags are not intended to "have their ultimate home in base" and are not really experimental features. That is the entire point of this proposal! Therefore we can exclude ghc-experimental and conclude that since we have no other candidates we are missing a package. Essentially I think these flags are just an edge case where ghc-internal and ghc-experimental both do not satisfy our present needs. This leads me to think we need something that will:

• never end up in base, hence this proposal.
• is user facing, but tightly coupled to GHC releases, thus excluding ghc-internal.

So I think a new packages similar to ghc-internal with these properties makes sense:

• shim ghc-internal
• is user facing and meant to be user facing.
• Is maintained and developed by GHC dev's given its proximity to GHC releases.

This reaches the goal, acknowledges the problem, and decouples ghc from base a little bit more than yesterday. The extra cost would be maintenance for this package but that is mitigated by keeping it under GHCHQ control.

The roadmap should be straight forward:

1. create the new package. It should live as close as possible to GHC, so in gitlab preferably as a submodule.
2. Copy the flags or types in base to this new package as they are.
3. keep the flags as they are in base, we can issue deprecation warnings once the new package is ready to be depended on, or do a clean break and add the new dependency to the impacted packages. That should be a very easy migration. My preference is still a clean break. But after 2, cleaning up base would be up to the CLC without requiring input from GHC devs. We just have to not allow both the new package and the flags in base to coexist long enough for both to become ossified in the ecosystem.
4. remove the flags and relevant types from base.

@TeofilC and everyone else. What else is in base that has similar properties to the RTS flags?

[TeofilC]

Great summary!

I think some of this was discussed in #146
Glancing through https://docs.google.com/spreadsheets/d/1WmyYLbJIMk9Q-vK4No5qvKIIdIZwhhFFlw6iVWd1xNQ/edit?gid=1315971213#gid=1315971213 it looks like most of the things marked "internalise" can just be exposed from ghc-internal.

So maybe it is just GHC.RTS.Flags and GHC.Stats?

[adamgundry]

There's also relevant discussion at https://gitlab.haskell.org/ghc/ghc/-/issues/25242: the new GHC.PrimOps should probably be treated similarly to whatever we agree here.

I'm still not seeing a compelling reason not to use ghc-experimental as the package that must be tightly coupled to GHC releases and maintained by GHC HQ in perpetuity, which is not free. That said, nothing stops us also having the package @TeofilC talks about in #289 (comment):

I'd be happy to maintain (or co-maintain!) something like this. There's a few more bits of base that would be good to eventually move into that package as well such as the GHC.Stats interface, etc. I think we could end up with a pretty nice coherent package.

I think this would be great to see as a separate package, which:

• Need not be maintained by GHC HQ or tightly coupled to GHC releases
• Can add shims so that the same API can cover a range of GHC versions
• Can depend on base for older GHCs and incur an additional dependency on ghc-experimental for newer GHCs

[tomjaguarpaw]

@adamgundry Are you suggesting to use ghc-internal (as it currently does) and re-export it from ghc-experimental? Or are you suggesting to move its definition site to ghc-experimental?

[adamgundry]

I think from a user perspective it doesn't much matter, does it? Whether the definition exists in ghc-internal or not is an implementation detail that can be resolved when this is implemented. (So, in practice, adding a re-export is probably the path of least resistance.)

My claim is that ghc-experimental is a suitable place to expose things (typically by re-export from ghc-internal) that

• are user-facing (ruling out ghc-internal as the only place they are exposed)
• are tightly coupled to GHC and change regularly (so need to live in a package that is released by the GHC maintainers alongside GHC)
• are not suitable for inclusion in base

[Ericson2314]

There are some things being discussed here that don't affect base and don't involve the CLC, and I think we might be best discussing them elsewhere.

The bottom line for the CLI is this:

• We cannot just continue reexport this from ghc-internals stuff in base, because then we can't change it without changing base.

• Two choices:

  • We could immediate remove it from base. It will eventually be exported from some other location. The CLC doesn't need to be involved in the choice of that other location. It only impacts base in that it appears in base's change log as part of the migration strategy.

  • We could re-implement the current interface in base atop the new ghc-internal changes (i.e. not doing so while not reexporting anything). Then future ghc-internal RTS options will not affect the frozen deprecated old interface in base. The CLC therefore doesn't need to be involved in further changes to the ghc-internal version.

This is close to what @doyougnu is saying, except reflecting the fact that the current implementation is already in ghc-internal.

So which choice are we doing? Once we decide on the decision for base's interface, we go back to the GHC issue tracker and involve fewer people and get things done with less overhead.

[doyougnu]

Hello, we discussed this in the latest GHC call. GHCHQ's view is to re-export these flags from ghc-internal into ghc-experimental leaving the current flags unchanged in base.

Is there anything left to discuss or can a vote begin?

[maralorn]

Just to make sure, was the opinion in the call, that it would actually be better for the current flags to stay in base, (e.g., less people depending on ghc-experimental) or that it is just less hazzle to keep it?

I have basically no stakes in using those flags, but I could imagine it getting confusing to users that there are a few flags which they can’t import from the place from which they get all others. In the long term only exposing them from ghc-experimental seems cleaner to me?

[doyougnu]

Just to make sure, was the opinion in the call, that it would actually be better for the current flags to stay in base, (e.g., less people depending on ghc-experimental) or that it is just less hazzle to keep it?

The opinion was to keep the flags in base for the time being to prevent more breakage, but to eventually remove them.

I have basically no stakes in using those flags, but I could imagine it getting confusing to users that there are a few flags which they can’t import from the place from which they get all others. In the long term only exposing them from ghc-experimental seems cleaner to me?

I agree and this is cleaner to me as well. IMHO there should just be a single source of truth for something like this. So I do not mean to imply that the flags in base will be kept there in perpetuity. I very much do still think they should be removed from base (that is the purpose of this proposal after all). But living with the redundancy opens the door to removing them whenever its convenient and giving the users that do depend on these flags an easy migration.

Did that clear things up?

[maralorn]

Just one last question: What exactly do you want the CLC to vote about? If there is no change to the base API intended now, there is nothing to vote on, is there?

[doyougnu]

Ah haha yea I guess that is right. Then I'm comfortable to park this until the changes in ghc-experimental happen.

[doyougnu]

I'm not entirely sure what is being asked of me now. I believed I had provided a proposal in the OP comment and provided two plans for implementation and requested a vote in the how to move forward part of that comment.

Since that comment we have decided

Not-clean break cannot simply re-export

If the implementation just re-exports then typeclasses will additional type class instances will leak.

Even if we re-make the API, type classes in Not-clean break will leak

@adamgundry suggested a refined not-clean break plan, but we concluded that that plan would leak instances of the underlying types, which could possibly create confusion, although I expect consumers of these flags to be experienced enough to not be confused (as @Bodigrim points out)

We have agreed that the dust should be settled for 9.14

even though this is up to the GHC devs.

IMHO, the first two points should are points against the not-clean break plan. edit see this comment

Other things

Regarding the number of users, I worry that these modules may be more widely used than the number of occurrences on Hackage indicate, because they are more likely to be useful in whole projects (especially GHC.Stats for monitoring purposes) than in redistributable libraries. It's hard to be sure, of course.

I agree, but let's take a closer look at the breakage we can assess. There are 22 libraries that are directly affected (excluding base)
base-compat-migrate, base-noprelude, bizzlelude, bizzlelude-js, boots-web, buffer, enumerate, fits-parse, generic-enum, generics-sop, ghc-instances, liquid-base, opaleye-textsearch, pragmatic-show, stack, staged-gg, staversion, store, streamly, streamly-core, text-show, typed-process

Of those libraries, the following libraries have not had a commit in the last four years:

• base-compat-migrate
• base-noprelude (9 years for this one)
• boots-web (only has two versions)
• buffer
• enumerate
• generic-enum
• ghc-instances (support stopped at GHC-8.2)
• liquid-base (deprecated, replacement does not depend on these flags, maintained by facundo)
• pragmatic-show (not quite true, one commit 3 years ago to add stack support)

These libraries have had at least one commit in the last year:

• bizzlelude (requires exactly base-4.17.2.1)
• bizzlelude-js (I couldn't find the source repo for this one, same constraints as bizzlelude on hackage though)
• fits-parse
• generic-sop (managed by WT)
• stack (did not check because stack)
• staversion
• store (maintained by fpcomplete)
• streamly (did not check because this is a popular lib)
• streamly-core (same as streamly)
• text-show (maintained by Ryan Scott)
• typed-process (maintained by fpcomplete)

Others:

• opaleye-textsearch (closed source, only has 36 total downloads off hackage and a single release)
• staged-gg (commits two years ago, maintained by phadej)

So to summarize:

• 9 libraries have not been updated in 4 years, this becomes 10 if we add opaleye-textsearch.
• Of the libraries that have been updated, I would say only 4: bizzelelude{-js}, fits-parse, and staversion are maintained by people not involved with day-to-day ecosystem/GHC development/maintainance.

My point being that:

• I expect breakage to be a headache for people actively involved in the ecosystem and GHC maintenance, but I also expect these people to welcome this kind of breakage in pursuit of a more stable base.
• Most of the breakage we can assess is breakage on abandoned packages. I believe these therefore should not carry the same weight as the libraries that are actively maintained.

So we are really talking about 12 packages, 8 of which are maintained by frequent Haskell ecosystem contributors and 4 of which aren't.

IMHO this means that the breakage we can assess is very small. Now can this be put to a vote? I would like to come away from this discussion with an approved plan (one of the plans we have been discussing or some modification of those plans) before I just start implementing. Like I said earlier, I prefer the clean break plan, but I am open to whatever is agreed on. I would just rather get on with it than continue to debate.

[tomjaguarpaw]

opaleye-textsearch (closed source, only has 36 total downloads off hackage and a single release)

FWIW, opaleye-textsearch is not closed source. The source is at https://gitlab.iscpif.fr/gargantext/opaleye-textsearch. I don't know why that's not mentioned in the cabal file. It imported GHC.RTS.Flags but didn't use the import. That's been fixed in a recent commit: https://gitlab.iscpif.fr/gargantext/opaleye-textsearch/commit/e00536ba2b12795207b9cc2633e4436e60bd9143. I guess that commit hasn't made it into any uploaded package.

[Bodigrim]

@adamgundry suggested a refined not-clean break plan, but we concluded that that plan would leak instances of the underlying types, which could possibly create confusion, although I expect consumers of these flags to be experienced enough to not be confused (as @Bodigrim points out)

There seems to be a confusion, the original plan of @adamgundry does not leak any instances.

[doyougnu]

There seems to be a confusion, the original plan of @adamgundry does not leak any instances.

Great. I've edited my previous comment. Can the CLC please vote on this now?

[tomjaguarpaw]

What are we being asked to vote on? Normally CLC votes on one specific proposal, with associated MR. But perhaps in this case you're asking the CLC to choose between "clean break" and "not-clean break" (as per #289 (comment))?

(Personally I support the not-clean break and oppose the clean break. t = two years seems long enough to me, t = one year seems not long enough. In the not-clean break world I think there should be a deprecation notice added to GHC.RTS.Flags in base under step 2.)

[doyougnu]

What are we being asked to vote on? Normally CLC votes on one specific proposal, with associated MR. But perhaps in this case you're asking the CLC to choose between "clean break" and "not-clean break" (as per #289 (comment))?

Yes this is what I am asking. I could open another proposal for the other plan but I think that is just redundant and I don't exactly want to issue an MR just to have the plan that the MR represents be rejected.

Per the proposal document, an MR is required when requested. It was not my understanding that such a request has been made.

[tomjaguarpaw]

Yes, makes sense to me. My vote would be

• not-clean break: +1
• clean break: -1

[Bodigrim]

I'm +1 on the plan in #289 (comment) and -1 on other suggestions.

(To be clear: this vote is non-binding and advisory only)

[hasufell]

I'm +1 for both. Or let's say: I don't really care.

This type of API is something that is naturally breaking all the time. So I feel doing elaborate deprecation is kinda moot. But if people want that, go ahead.

[Bodigrim]

@velveteer @parsonsmatt @angerman @mixphix any more non-binding opinions to help @doyougnu to choose the further course of action?

[angerman]

I'm with @tomjaguarpaw on this one. My vote would also be

• not-clean break: +1
• clean break: -1

[doyougnu]

MR opened: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13428

[Bodigrim]

@doyougnu is my understanding correct that you settled to implement #289 (comment)? Would you like CLC to vote?

[doyougnu]

@doyougnu is my understanding correct that you settled to implement #289 (comment)? Would you like CLC to vote?

Yes that is correct. Thanks for the followup!

[bgamari]

@doyougnu, can you update the proposal to reflect the current plan? In particular, there are several mentions of ghc-internal which I don't believe are intended.

[doyougnu]

@bgamari done. Here are the changes I added to the implementation section:

The plan is given by this comment. To be succinct we:

1. create compat functions and types in base. This is MR!13428 and is implemented, waiting on review.
2. move the flags to ghc-experimental and expose them through ghc-experimental. This is where consumers should expect to use these flags moving forward. This is MR!13343, it still needs work but should be trivial I just won't have time until this Friday.
3. Begin deprecating by adding warnings to the compat functions and types from (1). Not yet done.

[Bodigrim]

Dear CLC members, let's vote on the proposal to add a compatibility layer to GHC.Stats and GHC.RTS.Flags as described in #289 (comment). Currently these modules simply re-export GHC.Internal.Stats and GHC.Internal.RTS.Flags from ghc-internal, which means that every time GHC RTS adds a flag modules in base also undergo a breaking change. The proposal unties GHC.Stats and GHC.RTS.Flags from their counterparts in ghc-internals by providing a layer of compatibility shims. This allows to freeze the interface and allow underlying ghc-internals to change freely, without CLC involvement, but at the same time does not break existing users of these modules. The MR is available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13428.

@tomjaguarpaw @parsonsmatt @hasufell @angerman @velveteer @mixphix

---

+1 from me. We've been inundated with proposals to add GHC RTS flags (#288, #263, #254, #243), which isn't productive either for CLC or for GHC team, so uncoupling GHC.Stats and GHC.RTS.Flags from volatile GHC RTS without any breakage is a most welcome change.

(We shall probably deprecate and eventually remove them from base, but this is not an immediate proposal).

[mixphix]

+1

[hasufell]

+1

[tomjaguarpaw]

+1

[Bodigrim]

Thanks all, that's enough votes to approve.

[doyougnu]

Thanks all for your time, thoughts and labor!

[tomjaguarpaw]

Thank you for driving this forward!