Changes between Version 11 and Version 12 of GhcApiStatus

Timestamp:

06/05/08 03:46:30 (5 years ago)

Author:

claus

Comment:

hint, ghci, ast traversals, stable vs full api, ghc library path

GhcApiStatus

@@ -35 +35 @@
  * [http://www.haskell.org/haskellwiki/GHC/As_a_library GHC as a Library], the Haskell Wiki page
  * [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API GHC Commentary on the GHC API] (may be outdated)
+ * [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint-0.2.1 hint, an attempt to provide a simplified and stable subset of the GHC API]
 
 == Various Ideas, Comments, Questions ==
@@ -42 +43 @@
    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
+   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?
+ * 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)
+ * 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)
  * From {{{compiler/main/GHC.hs}}}:
 {{{
@@ -60 +64 @@
 --     - dictionary bindings
 }}}
+ * is there a way to make all the useful functionality of GHCi more easily available from the GHC API? ie, refactoring GHCi so that both it and other GHC API clients can use the same collection of useful functionality? (Claus Reinke)
  * dynamic loading of Haskell code, ala hs-plugins, but without
    the version/platform issues (GHCi has to be able to do this