I'm not so sure an automatic translation/simplification of the AST would be so useful for some tools. For example, say
Wait, how did refactorings get into this?-) The simplifications in this case are more like eliding details from the AST types, to represent the same source with different, simpler AST constructors, which can evolve independently, usually more slowly than the real GHC Ast constructors.
When we get to the .hi-file compatibility, that is slightly different, as we're talking about GHC-processed information rather than a direct representation of source: GHC Api client don't read the .hi-files explicitly, they ask the Api for some information, and the Api consults the .hi-files to produce that information. Inasmuch as that information involves GHC Api types that change between GHC versions, adding a compatibility layer might help here as well.
API users could import a specific version, say GHC_6_8 and we could provide backwards compatibility for some cases by translating some parts of GHC_6_10 into GHC_6_8 datatypes and fail for cases where this is not possible.
Or try to have a single extensible representation, with versioned information (assuming that interface files only get more detailed with newer GHC versions).
However, a fold-based interface may put less constraints on portability -- only function calls need to be portable, not data representations. However, you might have to transitively redefine lots of used data types as well this won't be practical either.
Yes, I don't think GHC can be retrofitted easily to support multiple runtime versions in one chunk of code. Pity, I liked the idea!-) Claus _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
