Use explicit namespace specifiers when promoting/singling fixity declarations #598
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.
During promotion, we now give promoted fixity declarations the
type
namespace, and during singling, we now give singled fixity declarations thetype
namespace (if it is a singled class declaration) or thedata
namesapce (for all other singled names). Doing so makes our intentions clearer, and it also future-proofs the code against planned GHC changes discussed in GHC proposal 65, where specifier-less fixity declarations (e.g.,infixl 4 %%%
) will become an error if they refer to both a term-level and type-level%%%
name.We now also take namespace specifiers into account when promoting fixity declarations. This is because
Wrinkle 1: When not to promote/single fixity declarations
inNote [singletons-th and fixity declarations]
describes a special case where we must avoid promoting fixity declarations for infix names, but this workaround only needs to be used if the fixity declaration lacks an explicit namespace specifier. If it does have an explicit namespace specifier (e.g.,infixl 4 data %%%
), then we can promote it (e.g., toinfixl 4 type %%%
) without fear of name clashes.Fixes #582.