"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote, > [Copying Tim and Ian Lynagh who might be interested.] > > | I noticed that Template Haskell support is included only in > | Stage 2 builds and that it depends on the availability of > | non-"base" libraries (in particular, "haskell-src"). > > Both true. > > | This > | seems to imply that Template Haskell features can neither be > | used inside GHC (in the same way, as eg RULES are used to > | simplify some optimisations inside GHC, such as constructor > | specialisation) > > You mean, can you use TH stuff in the GHC source code? Yes, of course > you can. You just need to compile that source code with at least a > stage-2 compiler. > > Aha. That means that we'd need to change the bootstrap process though. > At the moment we > > 1 Compile STAGE-1 with existing GHC (call it EXISTING) > 2 Compile STAGE-2 with STAGE-1 > 3 Compile STAGE-3 with STAGE-2 > > But if you use TH in the GHC source code, step 2 won't work. Instead > we'd have to > > 1 Compile STAGE-1 with EXISTING > 2 Compile STAGE-2 with EXISTING > > ...aha... I see what you mean. This won't work either. > > The point of the restriction to a stage2 compiler for GHCi and TH is > this. Consider a data structure built by running code compiled by > stage2 (e.g. as a result of running a top-level splice). This data > structure will be taken apart by the stage2 compiler itself, which was > compiled by stage1. So that's fine, because stage1 and stage2 are going > to agree on the layout of data structures, because they are the same > compiler. But EXISTING might have a different data structure layout. > > So there must be a stage in which a compiler X, compiled by EXISTING, is > compiling GHC. There is no guarantee that X and EXISTING share data > structure layouts, so it follows that GHC can't require TH extensions.
After the next release, say, GHC 6.0, there is a base compiler (= EXISTING) that supports TH. So, the post-6.0 CVS head could use TH. You may not want to do so immediately to allow people to build with older compilers, but at some point in the future this won't be an issue anymore. However, now the problem is that because Stage 1 does not include TH, we can never build Stage 2. So, the only reason that GHC cannot use TH is because of the two stage build process. I think that's essential what SimonM was saying, too. > | and worse TH stuff can't be used inside the standard > | libraries (unless we want to introduce a third stage). > > Can't be used in the 'base' package, but *only* base is needed to > compile GHC I think, so you can use TH in other packages (incl parallel > arrays). Just don't compile those libraries in STAGE1. At the moment, parallel arrays are in 'base'. They define stuff that is exported from PrelNames and friends. I think, SimonM said that it wouldn't be fundamentally difficult to define internally used names in other packages, but it may involve some hassle. However, don't we have a chicken and egg problem here again. Any names that are built-in need to be available in a Stage 1 build. So, no library that defines built-in names can use TH, which means parallel arrays can't use TH unless we can split the parallel arrays functionality up somehow. Correct? Moreover, it seems to me that GHC depends not only on "base", but it now *also* depends on "haskell-src" (as some GHC modules import Language.Haskell.THSyntax). Manuel _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
