X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=utils%2Fext-core%2FREADME;h=6a0dc137c506e77a9a7d95105c40c9f4945bea10;hb=6bc54d1524cd6d10a978bef89bc6a8f0061adb66;hp=6b8168d25b07b6d4e21acbc6c7a1637c15e9ef8d;hpb=276585028d51a2516a31b91a91a1f4bba5c9f8ba;p=ghc-hetmet.git diff --git a/utils/ext-core/README b/utils/ext-core/README index 6b8168d..6a0dc13 100644 --- a/utils/ext-core/README +++ b/utils/ext-core/README @@ -1,11 +1,74 @@ A set of example programs for handling external core format. In particular, typechecker and interpreter give a precise semantics. +--------------------- +tjc April/May 2008: -All can be built using, e.g., +==== Documentation ==== -happy -o Parser.hs Parser.y -ghc --make -package text -fglasgow-exts -o Driver Driver.hs +Documentation for the External Core format lives under docs/ext-core in the +GHC tree. If you are building from HEAD, do not rely on the version of the +External Core documentation that lives in haskell.org -- it is obsolete! + +==== Notes ==== + +The checker should work on most programs. Bugs (and infelicities) +I'm aware of: + +1. There's some weirdness involving funny character literals. This can + be fixed by writing a new lexer for chars rather than using Parsec's + built-in charLiteral lexer. But I haven't done that. + +2. The test driver attempts to find module dependencies automatically, + but it's slow. You can turn it off with the "-n" flag to the driver, + and specify all dependencies on the command line (you have to include + standard library dependencies too.) + * It would help to cache dependency info for standard libraries + in a file, or something, but that's future work. + +3. To avoid implementing some of the I/O primitives and foreign calls, + I use a gross hack involving replacing certain standard library + modules with simplified versions (found under lib/) that depend on + fake "primops" that the Core interpreter implements. This makes it + difficult (if not impossible) to load optimized versions of standard + libraries right now. Fixing this is future work too. + +Typechecking all the GHC libraries eats about a gig of heap and takes a +long time. I blame Parsec. (Someone who was bored, or understood happy +better than I do, could update the old happy parser, which is still in the +repo.) + +The interpreter is also memory-hungry, but works for small programs +that only do simple I/O (e.g., putStrLn is okay; not much more than that) +and don't use Doubles or arrays. For example: exp3_8, gen_regexps, queens, +primes, rfib, tak, wheel-sieve1, and wheel-sieve2, if modified so as not +to take input or arguments. + +==== Building ==== + +To run the checker and interpreter, you need to generate External Core +for all the base, integer and ghc-prim libraries. This can be done by +adding "-fext-core" to the GhcLibHcOpts in your build.mk file, then +running "make" under libraries/. + +Then you need to edit Driver.hs and change "baseDir" to point to your GHC +libraries directory. + +Once you've done that, the ext-core library can be built in the usual +Cabal manner: +1. runhaskell Setup.lhs configure +2. runhaskell Setup.lhs build +3. runhaskell Setup.lhs install + +Then, you can build the example Driver program with: + ghc -package extcore Driver.hs -o Driver + +And finally, you can use the included Makefile to run tests: + + make nofibtest (to run the parser/checker on all nofib programs... + for example.) + make libtest (to typecheck all the libraries) + +Tested with GHC 6.8.2. I make no claims of portability. -Most recently tested with GHC 6.8.1. I make no claims of portability. --tjc