On 11/03/14 07:19, Maxim Kulkin wrote:Actually, 1.16 was the bleeding edge release when 7.6.3 came out so
> 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.
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe