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,323
    • Issues 4,323
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 372
    • Merge Requests 372
  • 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
  • #18936

Closed
Open
Opened Nov 10, 2020 by John Ericson@Ericson2314Developer2 of 2 tasks completed2/2 tasks

Separate AST from GhcPass

One of the end-goals of TTG is a Haskell AST that can be used by GHC and other projects alike.

An impediment of this that the the TTG instances are in the same module as the data types which use the families. This means there is no way to even try to get a Haskell AST type without it's GHC-phase-specific ornaments. It would be good to separate:

  • Separate TTG type families from GhcPass / Pass, currently both are in GHC.Hs.Extension.
  • Separate AST data types from GHC-specific TTG type family instances, currently both are in the other GHC.Hs.* modules.

In the short term, I think this is best accomplished my baking more modules for just the AST types and families. Lots of helper functions are actually GhcPass-specific, (perhaps more than they need to be), but I wouldn't bother trying to deal with that at first as it leads to more complicated types / more type classes, which is controversial.

(This came up in the discussion of !1957 (closed), and also the mailing list on reducing the modules depended on by ghc-lib-parser)

CC @hsyl20

Edited Feb 18, 2021 by John Ericson
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#18936