Document Data.List changes in 9.4
Currently the Data.List monomorphisation is not mentioned in the release notes. Moreover, it would be great if we could provide guidance to users for automated refactoring strategies.
Activity
changed milestone to %9.2.1
added Ttask core libraries documentation labels
This change is mentioned in the
basechangelog, but it's incorrectly mentioned in the 4.16.0.0 section (it should be the 4.17.0.0 section, I believe). In fact, now that I look closer, there are several miscategorized things under the 4.16.0.0 section, including the mention of re-exportingasumfromControl.Applicative.
On 21/07/03 20:22, Richard Eisenberg wrote:
On Jun 20, 2021, at 10:57 AM, Edward Kmett ekmett@gmail.com wrote:
We definitely need to do more to communicate that this is changing and how users should adjust their code to suit.
Yes, I agree! Who is responsible for actually doing this communication, though? I don't think it should just be tucked into the release notes. This will be a major source of breakage in the next release.
Richard
@rae Instinctively I would say that the CLC would have the duty to make public such change and provide the necessary migration solutions?
I tend to agree, but I'd like to be more specific: who within @core-libraries will actually do it? I think this has the chance of turning into another story that bolsters the argument that Haskell does not care about backward-compatibility. We need to get out in front.
Indeed, I would have made noises against this change if I had been aware of the debate. I'm on the libraries@ list, but this particular, large change was debated in a thread that started just about adding
singleton, which I had decided to stay out of. When the patch arrived, I asked for a pointer to any documentation of the debate, and was just referred to the thread, where it seemed a few voices just said "yes, let's pull the trigger". We really need a public process for this -- I imagine most would consider me an insider, and yet I was caught by surprise here.-
@chessai @emilypi @gwils @ndmitchell Can the CLC meet and propose a transition plan regarding this change?
@Kleidukos - I was unaware of this change, and I don't think I'm a member of the CLC (at the very least, I don't receive any emails at all).
-
@ndmitchell Ah my bad, it looks like the Wiki page hasn't been updated since 2020 (which was the year your term ended). (I fixed that)
Edited by Hécate Kleidukos 
The Data.List change has broken hundreds of packages, including ones which have not been updated in years. OTOH, my understanding of the benefit is that it makes it consistent with other contains modules which you normally export qualified and this seems like a very small win in comparison. In my opinion, the breakage nowhere near justifies the cost and it should be reverted. Until now it is mostly GHC developers feeling this I think because we are using HEAD to build many packages and updating head.hackage regularly.
I agree strongly with Richard's point about not seeming to not care about backwards compat, this change seems to provide only aesthetic benefits but produces magnitudes of busy-work!
The plan as described at https://groups.google.com/g/haskell-core-libraries/c/q3zHLmzBa5E (I cannot find any vote on it, however) was
1.) introduce singleton into Data.List in the next major GHC release.
2.) work with GHC HQ to see if we can't get some warning of unqualified imports of the Foldable re-exports from Data.List,blocking further changes to Data.List until we get a plan that works.
3.) monomorphize the remaining combinators in Data.List after a suitable 1-2 GHC release warning period, switching to the versions currently buried in GHC.OldList. (The three-release policy doesn't bite this at all, as using qualified imports would work across both monomorphic and polymorphic versions of those combinators.)
4.) Retire GHC.OldList after a suitable migration period to comply with the 3-release policy.
I do not really see (2) has happened in the wild yet, so I would say that (3) should be at least postponed.
I do not really see (2) has happened in the wild yet, so I would say that (3) should be at least postponed.
It did happen: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/using-warnings.html#ghc-flag--Wcompat-unqualified-imports
I don't believe in postponing. People simply ignore warnings.
Edited by Oleg Grenrus-
@phadej this warning is hidden beyond
-Wcompat, which means that almost nobody have seen it. Moreover, if you importfoldfromData.List, the warning suggests importingData.Listqualified. But it should really suggest importingData.Foldableinstead! 
FWIW I visit the GHC tracker regularly to skim issues, test my packages with unreleased GHC versions and I had zero idea that this change was happening.
IMO it was very poorly communicated for such a breaking change and I'd argue it should be at least postponed.
Edited by Andrzej Rybczak@carter you have no vote. It's up to current CLC members to change the course of action. Ping @chessai, @emilypi, @andrewthad, @gwils.
The change has already landed and alphas are already out, so I'm reluctant to revert. It's my fault that the change came so fast and without proper communication/damage assessment. Here is my proposal for what to do:
- Fix the changelog
- Assess damages using head.hackage and/or pump tool
- Begin fixing packages (possibly from the top 500)
- Communicate the changes widely while fixes are ongoing
- Implement changes to the process so this doesn't happen again
(3) should always happen for breaking changes to core libraries and (5) should come down to a more formal process
I can give time to (3) but there's no way I can do it alone in a short time frame.
-
The change has already landed and alphas are already out.
No,
Data.Listin 9.2 alpha is still polymorphic: https://downloads.haskell.org/~ghc/9.2.1-alpha2/docs/html/libraries/base-4.16.0.0/Data-List.html#v:length (The title of this ticket is misleading, I believe, it should be 9.4 instead of 9.2)@chessai could you please clarify whether CLC took a vote in favor of this change? Was the outcome communicated publicly in any form?
The CLC discussed and voted on it privately and announced it here, in 2019 (note that this was before my time): https://mail.haskell.org/pipermail/libraries/2019-September/029930.html
-
This email definitively announces only adding
Data.List.singleton. Everything else is very vague, e. g., monomorphisation is mentioned in passing, as a distant future development of qualified import ofData.List(which is not a state we are in at the moment). The migration plan is mentioned as “being hammered out”, but apparently was never finished/published.Edited by Bodigrim
A revert will likely be much less engineering. This change doesn’t introduce anything new abstraction wise, just a tad bit of consistency.
@bgamari how much work would a release candidate with a revert be? It’s a shame if we commit to breaking long stable code that’s not needed a change in years for no good reason.
