On Tue, Sep 18, 2012 at 04:28:34PM +0000, Simon Peyton-Jones wrote:
> | If I've understood correctly, then haskell-src-exts would be more than
> | just a boot package: It would be intimately tied to GHC. Any change in
> | its interface would need to be reflected in the compiler (e.g.
> | compiler/hsSyn/Convert.lhs, compiler/deSugar/DsMeta.hs).
>
> Yes, that would be right. In a sense containers is like that too though; if
> Data.Map is changed, so much GHC's source code change. Does that make it
> "more than a boot package"? But the coupling is particularly intimate for
> TH; GHC must know about every data constructor in the syntax tree.
It's not an entirely black-and-white thing, I grant you, but you can use
any version of containers with any version of GHC when you're compiling
your own code [1], but when using Template Haskell you can only use
versions of template-haskell that precisely match the compiler's
wired-in names.
It's true that in principle you could use a different version of
template-haskell (or haskell-src-exts, in the future) provided you were
only using its datastructures for other things, not for Template
Haskell. However, I think it would result in a lot less confusion if we
simply have cabal disallow installing a different version of
template-haskell/haskell-src-exts than comes with the compiler.
[1] That's a slight simplification, of course: You can only use versions
of containers that that version of GHC can compile, and if your own
code uses the GHC API then you may need to use the same version of
containers that the GHC API uses.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
