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,262
    • Issues 4,262
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 419
    • Merge Requests 419
  • 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
  • #10827

Closed
Open
Opened Sep 02, 2015 by Edward Z. Yang@ezyangDeveloper

GHCi should support interpeting multiple packages/units with separate DynFlags

Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), stack build builds all of them. They are quite interested in support stack ghci but there are problems: https://github.com/commercialhaskell/stack/issues/665


edit: These are Edward's original technical notes. The new plan is in https://gitlab.haskell.org/ghc/ghc/-/wikis/Multi-Session-GHC-API . Both his 1) and 2) are solved dispensing with a notion of a single "home package", and instead having multiple, with their own flags (including src dirs) etc.

The essence of the problem is twofold:

  1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden).
  2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages.

It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys.

Similar functionality would be useful for Backpack.

Trac metadata
Trac field Value
Version 7.11
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHC API
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Edited Jul 11, 2020 by John Ericson
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#10827