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

Adapt to DLamCasesE in th-desugar-1.18 #595

Merged
merged 1 commit into from
Jun 25, 2024
Merged

Conversation

RyanGlScott
Copy link
Collaborator

This patch bumps the pinned th-desugar commit to bring in the changes from goldfirere/th-desugar#218, which replaces DLamE and DCaseE in favor of DLamCasesE. Quite happily, this actually simplifies how singling works in singletons-th. Previously, we went through great efforts to annotate promoted case expressions with their overall return type, as described in Note [Annotate case return type] and Note [The id hack; or, how singletons-th learned to stop worrying and avoid kind generalization] in D.S.TH.Single. After this patch, however, all case expressions are desugared to \cases expressions, and because we already annotate singled \cases expressions (by generating code like singFun1 @LamCasesSym0 (\cases ...)), we no longer need to use the tricks describes in those two Notes. Hooray!

One interesting knock-on effect of these simplifications is that given code like this:

map (\x -> ()) xs -- Note that `x` is unused

singletons-th would previously generate code that looked like this:

sMap (singFun1 @LamdaSym0 (\sX -> case sX of (_ :: Sing x) -> STuple0)) sXs

Unlike the original code, this singled code would compile without warnings. This is because sX is "used" in the sense that it is passed to a case expression. It's a very silly case expression, as it doesn't do anything meaningful with sX, but it still technically counts as a use.

Now that singletons-th uses a \cases-based approach to singling, however, the singled code will instead look like this:

sMap (singFun1 @LamCasesSym0 (\cases (sX :: Sing x) -> STuple0)) sXs

This time, GHC does recognize that sX is unused and emits a warning. This actually affects the way that singletons-th generates code for derived Functor and Foldable instances, so I needed to generate wildcard patterns instead of variable patterns in certain parts of
D.S.TH.Promote.Deriving.{Functor,Foldable}. I have also mentioned the possibility of singletons-th generating more warnings in the CHANGELOG.

This patch bumps the pinned `th-desugar` commit to bring in the changes from
goldfirere/th-desugar#218, which replaces `DLamE` and
`DCaseE` in favor of `DLamCasesE`. Quite happily, this actually _simplifies_
how singling works in `singletons-th`. Previously, we went through great
efforts to annotate promoted `case` expressions with their overall return type,
as described in `Note [Annotate case return type]` and `Note [The id hack; or,
how singletons-th learned to stop worrying and avoid kind generalization]` in
`D.S.TH.Single`. After this patch, however, all `case` expressions are
desugared to `\cases` expressions, and because we already annotate singled
`\cases` expressions (by generating code like `singFun1 @LamCasesSym0 (\cases
...)`), we no longer need to use the tricks describes in those two Notes.
Hooray!

One interesting knock-on effect of these simplifications is that given code
like this:

```hs
map (\x -> ()) xs -- Note that `x` is unused
```

`singletons-th` would previously generate code that looked like this:

```hs
sMap (singFun1 @LamdaSym0 (\sX -> case sX of (_ :: Sing x) -> STuple0)) sXs
```

Unlike the original code, this singled code would compile without warnings.
This is because `sX` is "used" in the sense that it is passed to a `case`
expression. It's a very silly `case` expression, as it doesn't do anything
meaningful with `sX`, but it still technically counts as a use.

Now that `singletons-th` uses a `\cases`-based approach to singling, however,
the singled code will instead look like this:

```hs
sMap (singFun1 @LamCasesSym0 (\cases (sX :: Sing x) -> STuple0)) sXs
```

This time, GHC _does_ recognize that `sX` is unused and emits a warning. This
actually affects the way that `singletons-th` generates code for derived
`Functor` and `Foldable` instances, so I needed to generate wildcard patterns
instead of variable patterns in certain parts of
`D.S.TH.Promote.Deriving.{Functor,Foldable}`. I have also mentioned the
possibility of `singletons-th` generating more warnings in the `CHANGELOG`.
@RyanGlScott RyanGlScott merged commit b385b36 into master Jun 25, 2024
24 checks passed
@RyanGlScott RyanGlScott deleted the T210-lambda-case branch June 25, 2024 23:57
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.

1 participant