|41|| || * '''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)
|Would it be possible to separate the monolithic GHC API into two parts, one providing a simplified and stable subset/wrapper of commonly used functionality (as in Hint, hs-plugins, GHCi), the other providing all the rest, with no stability guarantees?
|47|| || *
|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) see: GhcApiAstTraversals
|50|| || *
|David Waern mentions [http://www.haskell.org/pipermail/haskell-cafe/2008-May/042961.html deriving `Data.Traversable`] for GHC's AST
|* the need to hardcode the '''GHC library directory in GHC API clients''' is very fragile and troublesome (cf. the [http://www.haskell.org/pipermail/cvs-libraries/2008-June/008942.html Haddock version during build] thread on `cvs-ghc` for just one example). would it be possible to integrate the path for the compiling GHC as a default, so that one only needs to specify an explicit path if the default doesn't work (compiling GHC moved/unavailable)? (Claus Reinke) this has been addressed by the new [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths ghc-paths] package
| ||41|| * '''Interface Stability'''
| ||47|| *
| ||50|| *
| ||51|| e