On 11/03/14 07:19, Maxim Kulkin wrote:
I played a bit with GHC API and Cabal (and even implemented .cabal support for hdevtools) and now I see issues with this approach:
1. GHC depends on Cabal (rly?) and this is most likely some old version of Cabal, not the one you use currently (e.g. I use cabal-install and Cabal 1.18, but GHC 7.6.3 -- the latest stable -- depends on Cabal 1.16). This makes it hard to develop tools that both use GHC API and latest Cabal. Hopefully this dependency will be removed in future versions of GHC.
Actually, 1.16 was the bleeding edge release when 7.6.3 came out so technically it was new. Old compiler depends on an old version, I don't see why you find this odd. 7.8 will ship with a newer version (whether we like this or not). Having said that, I don't think GHC API depends on Cabal API, does it?
2. Sometimes you get stuck with types and can't get source code compile and GHC API-based tools are of no help in this situation, because they won't be able to provide type for some variable in source file because this source file contains a syntax/type error in some other part. I'm not sure if GHC API can be tweaked to bypass errors and do the best effort of parsing/desugaring of other parts of sources with errors. Maybe some external parser (haskell-src-exts) should be used for source inspection.
-- Mateusz K.