Version 6 (modified by nominolo, 9 years ago) (diff)


GHC API Improvement Status

This Wiki page shall serve as a central place to collect all issues and ideas related to the GHC API. If you feel that something is missing from this page, please put it here.

Trac Tickets Related to the GHC API

  • #1467 - GHC API: expose separate compilation stages
  • #1886 - GHC API should preserve and provide access to comments
  • #654 - Cabalization of the GHC library.
  • #1631 - Make the External Package Table contain ModDetails not ModIface

Possibly Related

  • #2159 - Use a more efficient representation than [DynFlag]

Related Documents and Discussions

Various Ideas, Comments, Questions

  • Interface Stability - Is there a way to reduce version-skew for clients of the GHC API (currently, there is no stability guaranteed at all, so if you don't want to live with lots of #ifdefs and breakage, you keep delaying your fantastic GHC API-base projects "until the dust settles") (Claus Reinke)
  • Is it possible to use standalone deriving to get a generic programming framework over the ASTs without blowing up GHC's code for its own use (deriving Data, etc.)? (Claus Reinke)
  • From compiler/main/GHC.hs:
    -- NOTE:
    --   - things that aren't in the output of the typechecker right now:
    --     - the export list
    --     - the imports
    --     - type signatures
    --     - type/data/newtype declarations
    --     - class declarations
    --     - instances
    --   - extra things in the typechecker's output:
    --     - default methods are turned into top-level decls.
    --     - dictionary bindings
  • dynamic loading of Haskell code, ala hs-plugins, but without the version/platform issues (GHCi has to be able to do this anyway, but it would be nice to have the ugly bits hidden, such as unsafeCast#, or whatever it was). that might require a standard for typeReps, if I recall correctly.. (Claus Reinke)