X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=blobdiff_plain;f=utils%2Fext-core%2FREADME;fp=utils%2Fext-core%2FREADME;h=0000000000000000000000000000000000000000;hp=8191b716de61216bef2f42251db4c05753e66e4f;hb=0434f5bf9a2712a99e9e6c99d67991a3f09af91d;hpb=e6232609a0b08ff7136a479f2e2d7d2be5040b1d

diff --git a/utils/ext-core/README b/utils/ext-core/README
deleted file mode 100644
index 8191b71..0000000
--- a/utils/ext-core/README
+++ /dev/null
@@ -1,83 +0,0 @@
-This package has moved to Hackage!
-http://hackage.haskell.org/package/extcore-0.2
-
-The version of the stand-alone External Core library in the GHC
-source tree is now out-of-date, and will probably go away eventually.
-Please get the latest version from Hackage.
-
-=====================================================================
-
-A set of example programs for handling external core format.
-
-In particular, typechecker and interpreter give a precise semantics.
----------------------
-tjc April/May 2008:
-
-==== Documentation ====
-
-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.
-
-