There is a better way to parse record fields (ApplicativeDo + RecordWildCards)#12107
Open
Bodigrim wants to merge 1 commit into
Open
There is a better way to parse record fields (ApplicativeDo + RecordWildCards)#12107Bodigrim wants to merge 1 commit into
Bodigrim wants to merge 1 commit into
Conversation
c58e41f to
fb25a1d
Compare
zlonast
approved these changes
Jul 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Parsing of arguments in Cabal is typically organised as a humongous sequence of
(<*>). Here is an example:cabal/cabal-install/src/Distribution/Client/ProjectConfig/FieldGrammar.hs
Lines 113 to 261 in 996d9e0
This is inconvenient to read and error prone to write. Half of the fields here are of the same type
Flag Bool, so one can easily swap two of them and never notice a mistake. If you remove a field ofPackageConfig, you'll be presented with a very long error message saying that it cannot apply, say, 30th argument out of 60+ of them. If you add a field toPackageConfig- same story, the error message will talk about function of 60+ arguments (aka constructor) having a wrong type at some position. This is not a sane way to work with records.There is a known pattern of
ApplicativeDo + RecordWildCardswhich fixes these issues. Here is an updated example:cabal/cabal-install/src/Distribution/Client/ProjectConfig/FieldGrammar.hs
Lines 113 to 196 in 07c8c76
Now everything has names. If you remove a field, you get a warning about an unused variable (and GHC will be able to pinpoint which line exactly). If you add a field, you get a warning about uninitialized field (and GHC will tell you the name of the missing field).
Template B: This PR does not modify behaviour or interface
Include the following checklist in your PR: