Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use explicit namespace specifiers when promoting/singling fixity declarations #598

Merged
merged 1 commit into from
Jun 6, 2024

Conversation

RyanGlScott
Copy link
Collaborator

During promotion, we now give promoted fixity declarations the type namespace, and during singling, we now give singled fixity declarations the type namespace (if it is a singled class declaration) or the data 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 in Note [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., to infixl 4 type %%%) without fear of name clashes.

Fixes #582.

Comment on lines +125 to +128
infixl 4 %%%
infixl 4 `Foo`
infixl 4 %%%%
infixl 4 `sFoo`
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was surprised to see that these generated fixity declarations seemingly lacked namespace specifiers. Some investigation reveals that the declarations actually do have namespace specifiers, but due to a GHC pretty-printing bug, the namespaces don't get printed in the -ddump-splices output. Thankfully, the generated code still behaves as expected, but we'll have to live with some counterintuitive golden output until that GHC bug gets fixed upstream.

…arations

During promotion, we now give promoted fixity declarations the `type`
namespace, and during singling, we now give singled fixity declarations the
`type` namespace (if it is a singled class declaration) or the `data` 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](https://github.com/ghc-proposals/ghc-proposals/blob/8443acc903437cef1a7fbb56de79b6dce77b1a09/proposals/0065-type-infix.rst#migration-plan),
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` in `Note [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., to `infixl 4 type
%%%`) without fear of name clashes.

Fixes #582.
@RyanGlScott RyanGlScott merged commit 2b4f955 into master Jun 6, 2024
24 checks passed
@RyanGlScott RyanGlScott deleted the T582-namespace-specifiers branch June 6, 2024 11:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support promoting/singling namespace specifiers in fixity declarations
1 participant