Changes between Version 13 and Version 14 of GhcApiStatus


Ignore:
Timestamp:
Jul 15, 2008 9:18:56 AM (6 years ago)
Author:
claus
Comment:

add binary incompatibility and direct error output issues, plus a little cleanup

Legend:

Unmodified
Added
Removed
Modified
  • GhcApiStatus

    v13 v14  
    3939== Various Ideas, Comments, Questions == 
    4040 
    41  * '''Interface Stability''' - Is there a way to reduce version-skew for clients of the GHC 
    42    API (currently, there is no stability guaranteed at all, so if you 
    43    don't want to live with lots of #ifdefs and breakage, you keep 
    44    delaying your fantastic GHC API-base projects "until the dust 
    45    settles") (Claus Reinke)  
    46    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 
    48    programming framework over the ASTs''' without blowing 
    49    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 
    51  * 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'''  
     42   - 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) 
     43   - 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? (Claus Reinke) 
     44 * '''Ast Traversals/Queries''', see: GhcApiAstTraversals 
     45   - 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) 
     46   - David Waern mentions [http://www.haskell.org/pipermail/haskell-cafe/2008-May/042961.html deriving `Data.Traversable`] for GHC's AST 
     47 * '''GHC library directory in GHC API clients''' 
     48   - the need to hardcode the libdir 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)  
     49   - this has been addressed by the new [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths ghc-paths] package 
     50 * '''binary incompatibility of GHC versions''' 
     51   - this also affects GHC Api clients, see [http://www.haskell.org/pipermail/cvs-ghc/2008-July/043568.html the Haddock 2 in GHC build issues] for an infamous example 
    5252 * From {{{compiler/main/GHC.hs}}}: 
    5353{{{ 
     
    7070   such as {{{unsafeCast#}}}, or whatever it was). that might require 
    7171   a standard for typeReps, if I recall correctly.. (Claus Reinke) 
     72 * since the refactoring ideas below mention error handling: it appears that some GHC Api functions output error messages directly, without providing a means to handle/capture them in callers. I ran into one such instance a while ago (#1463, comments 8, 10, 11) 
    7273 * ... more comments here ... 
    7374