core-libraries-committee
core-libraries-committee copied to clipboard
haskell
Export `Data.Traversable.for` from the Prelude
I did not test clc-stackage as there are many packages with version bounds in both the current cabal file and the latest Stackage Nightly release that do not include base-4.19.
I did not test clc-stackage as there are many packages with version bounds in both the current cabal file and the latest Stackage Nightly release that do not include base-4.19.
That is very bad excuse. You are a member of CLC, if you don't bother to do that yourself, dont' ask anyone else either.
E.g. it looks that
Agdawill break https://hackage-search.serokell.io/viewfile/Agda-2.6.4.1/src/full/Agda/Utils/Functor.hs#line-33hakyllhttps://hackage-search.serokell.io/viewfile/hakyll-4.16.2.0/lib/Hakyll/Web/Template/Internal/Element.hs#line-204statisticshttps://hackage-search.serokell.io/viewfile/statistics-0.16.2.1/Statistics/Function.hs#line-125streaming-bytestringhttps://hackage-search.serokell.io/viewfile/streaming-bytestring-0.3.2/lib/Streaming/ByteString.hs#line-650
@mixphix could you please give another go to https://github.com/haskell/clc-stackage? I was able to build it in full recently.
(You'd have to backport your changes from GHC master to ghc-9.8 branch, there is no newer Stackage)
If we're going to do this kind of thing could it be done based on an assessment of what actually gets imported from non-Prelude base libraries in practice?
I'm not sure I understand what you mean, @tomjaguarpaw. Should we open a poll on the Discourse for this? Perhaps we can include some other functions in the poll and export the top 3. Personally, as the proposal author, exporting for is enough for me.
@Bodigrim I'll give it a try this week, thanks for the update.
I was thinking of doing an analysis of all code on Hackage to determine which identifiers are most imported from modules in base and adding the most commonly imported ones to the Prelude (in the absence of obvious name clashes, etc.).
Am I to assume that these maintainers will want such imports to disappear? Many heavy-duty libraries in the Haskell ecosystem still emit warnings from before the Functor–Applicative–Monad proposal. Those who object to this, much smaller, scope, can do so in this thread dedicated to exporting for from the Prelude. Until then, please refrain from derailing it.
As you wish. I think your proposal would be much stronger if it was backed by numerical evidence, but you're free to manage it as you prefer, of course.
I would like to express a weak preference against this, because I have always felt that Data.Traversable.for is a misnomer in a world where we have forM = flip mapM. I have always wanted for = flip Data.List.map.
I would like to express a weak preference against this, because I have always felt that
Data.Traversable.foris a misnomer in a world where we haveforM = flip mapM. I have always wantedfor = flip Data.List.map.
Sure, it would been more consistent to have Functor with map (and for) (and have the monomorphic Data.List.map not in the prelude), Traversable with mapA/forA (Applicative) and mapM/forM; but that renaming won't happen; so I guess the ecosystem is stuck with the current naming scheme.
@Bodigrim I am unable to access my GitLab account because I cleared my 2FA app and lost my recovery codes. Who can I contact to resolve this?
@mixphix the best is to drop a message to https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs, but also CC @chreekat.
Isn't for used for some streaming/iteration stuff? It doesn't strike me as a great word to steal.
I want to reiterate that this for is the one from Data.Traversable, which permits Applicative actions.
@chreekat Unfortunately not, I was forbidden from emailing the ghc-devs mailing list and received no response from ghc-devs-owner.
@mixphix ok, can you email me at [email protected] from the email address associated with your account?
I was able to log in and set up 2FA again. Thanks @chreekat and @Bodigrim. I've left a comment on the MR thread as well.
After compiling as much of clc-stackage as I could with the GHC using the changes from this MR, I found 27 ambiguities in 14 packages:
- Agda
- BNFC
- blaze-bootstrap
- contiguous
- crypto-api
- dense-linear-algebra
- extrapolate
- hakyll
- netwire
- pipes
- streaming
- threepenny-gui
- xml-picklers
- yjtools
Should the proposal pass, these are the libraries I'll submit pull requests to.
Thanks! Note that the proposal process asks for patches to be prepared upfront (but not submitted as PRs):
- Patching affected packages locally would allow you to progress further in impact assessment, beyond the first level of breakage.
- Looking at patches helps CLC to determine the scale of breakage and to formulate a migration guide.
To be more specific, pipes and streaming are dependencies of many packages, so it would be really important to patch them locally (cabal unpack them somewhere, patch and add the folder to cabal.project) to progress further.
What's the suggested migration guide for pipes and streaming? Both APIs contain for functions, incompatible with Prelude: Pipes and Streaming.Prelude. At least Pipes are often imported unqualified. Should they be advised to rename the combinator (which is a breaking change for them and consumers)? Or should consumers be advised to import Pipes qualified? Or just keep import Prelude hiding (for) everywhere for foreseeable future?
Same question for other packages offering for in public API, see https://www.stackage.org/lts-22.33/hoogle?q=for for an approximate list. I suspect that quite a few of them are usually imported unqualified.
I am still not able to compile a full working version of clc-stackage with the GHC 9.8 produced from altering the Prelude, due to more errors from the constraint solver than from the ambiguities, which works out to be closer to 40 packages with dependencies, especially from pipes and streaming ecosystems. This has been much more effort than writing import Data.Traversable (for) in the source files I need.