Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,248
    • Issues 4,248
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 397
    • Merge Requests 397
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #16762

Closed
Open
Opened Jun 06, 2019 by Richard Eisenberg@raeDeveloper

Refactor implicit/explicit binders.

Because of the forall-or-nothing rule, there are many places where we can have implicit binders, or explicit binders, but not both. One such place is a function type signature, stored by LHsSigType, with:

type LHsSigType   pass = HsImplicitBndrs pass (LHsType pass)    -- Implicit only

If the user has written a forall, then the type there is a HsForAllTy. This HsForAllTy is special, though, in that it triggers the forall-or-nothing rule and interacts specially with -XScopedTypeVariables.

This ticket tracks the idea of refactoring this situation so that HsImplicitBndrs becomes HsTvBndrs and contains either implicit binders or explicit binders. The new construct will only be used where the forall-or-nothing rule is in effect, and I think will completely replace all uses of HsImplicitBndrs. This will simplify code (there are several places that bring implicits and explicits into scope, but one of these lists is always empty) and align the AST more closely with the semantics of user-written code.

There was some discussion of this in another ticket, but I've completely lost where. If you (for any value of "you") know, please link.

Assignee
Assign to
9.2.1
Milestone
9.2.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#16762