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,322
    • Issues 4,322
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 357
    • Merge Requests 357
  • 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
  • #19218

Closed
Open
Opened Jan 14, 2021 by John Ericson@Ericson2314Developer

Move AST into it's own package

Motivation

The end goal of TTG is to share extensible data types for Haskell's syntax between GHC and other projects. But if we are to do that, we should have those data types live in a separate package.

  • This is more robust at preventing entanglement than e.g. "the parser dependencies test"
  • Eventually things might stabilize enough that the base extensible AST doesn't have a breaking change every GHC release. That mean less churn on PVP bounds for consumers of just the AST and not the rest of GHC.
  • Hopefully, this can be the beginning of modularizing GHC more broadly :).

The relevant TTG wiki page is here

Proposal

The big question is of course how we get there. The key trick is to do work getting ready to separate the AST into it's own package before actually doing it, because its too much of a refactor to do all at once.

  • #18936 (closed) This talks about how to remove a major part of the GHC-specific stuff from the module
  • In !4778 (comment 323748) @SPJ talks about using a different module hierarchy to indicate to other programmers the intent for these modules tot be separate from GHC. I think that's a great idea.
Edited Jan 14, 2021 by Simon Peyton Jones
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#19218