ghc package depends on exact version of Cabal pacakge. I understand why old
package depends on some other old package. I just don't understand why GHC
depends on Cabal.
On Tue, Mar 11, 2014 at 11:26 AM, Mateusz Kowalczyk wrote: 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe