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

Record local variables' kinds during lambda lifting #610

Merged
merged 1 commit into from
Jun 30, 2024

Commits on Jun 26, 2024

  1. Record local variables' kinds during lambda lifting

    Previously, `singletons-th` made no effort to track the kinds of local
    variables when generating lambda-lifted code, instead generating local variable
    binders with no kind annotations. As a result, GHC would generalize the kinds
    of these lambda-lifted definitions to things that are way more polymorphic than
    intended. While this technically works in today's GHC, it won't in a future
    version of GHC that implements
    [GHC#23515](https://gitlab.haskell.org/ghc/ghc/-/issues/23515).
    
    In general, generating kinds for every local variable would require
    `singletons-th` to implement something akin to full-blown type inference over
    the Template Haskell AST, which is not something I am eager to implement.
    
    Fortunately, there is a relatively simple approach we can do to alleviate this
    problem that doesn't require full type inference. In situations where we know
    the kind of a local variable (e.g., when there is a top-level signature or
    there is a pattern signature), we record the variable's kind and use it when
    generating binders for any lambda-lifted definitions that close over the
    variable. For the full story on how this works, see `Note [Local variables and
    kind information]` `D.S.TH.Promote.Syntax.LocalVar`.
    
    This is not a perfect solution, as there will still be examples of the original
    problem that won't be covered by this simple approach (see the Note). This
    approach is still much better than what `singletons-th` was doing before, and I
    think it's worth using this simple approach even if it doesn't fix 100% of all
    cases.
    
    This patch mostly resolves the "Overly polymorphic lambda-lifting, part 2"
    section of #601.
    RyanGlScott committed Jun 26, 2024
    Configuration menu
    Copy the full SHA
    38454cb View commit details
    Browse the repository at this point in the history