extcore: Libraries for processing GHC Core

[ bsd3, language, library ] [ Propose Tags ]

Libraries for processing GHC Core

[Skip to Readme]
Versions 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1, 0.9.2, 1.0, 1.0.1, 1.0.2
Change log CHANGES
Dependencies array, base (==4.*), bytestring, containers, directory, filepath, mtl, parsec, pretty, syb [details]
License BSD-3-Clause
Author Andrew Tolmach, Tim Chevalier, The GHC Team
Maintainer Tim Chevalier <chevalier@alum.wellesley.edu>
Category Language
Uploaded by TimChevalier at Sun May 23 00:57:12 UTC 2010
Distributions NixOS:1.0.2
Downloads 5319 total (32 in the last 30 days)
Rating 2.0 (votes: 1) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI




Maintainer's Corner

For package maintainers and hackage trustees

Readme for extcore-0.8

[back to package description]
A set of example programs for handling external core format.

In particular, typechecker and interpreter give a precise semantics.

==== Documentation ====

Documentation for the External Core format lives under docs/ext-core in the
GHC tree (for the most current version). In general, a PDF version lives at:

==== Building ====

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

The file Language/Core/PrimEnv.hs can be automatically generated from GHC's
primop table. This distribution (as of September 2009) contains a snapshot
of GHC 6.10.4's primops. See the sources for Setup.lhs in this directory
for how to re-generate this file from a more recent version of GHC (you need
a GHC build tree if you want to do this.)

==== Running the code ====

The easiest way to run the included checker and interpreter is to
install and use the Core Linker, which combines multiple External Core
source files into a single source file. Since even a very simple GHC-
compiled program relies on many different library modules, this makes
the code easier, and (as of September 2009) I haven't recently tested
the checker and interpreter on Core programs consisting of sets of 
multiple modules.

The Core Linker lives at:

To use the tools, you need to generate External Core for all the base,
integer and ghc-prim libraries. You need a GHC source tree for
this. Adding "-fext-core" to the GhcLibHcOpts in your build.mk file,
then run "make" under libraries/.

If you want to run the sample interpreter, then before doing the previous
step, you need to apply some library patches that circumvent some of
GHC's implementations of I/O functions to avoid exposing primops that the
ext-core interpreter doesn't know how to do. In this directory, you'll
find a patch called simple_io.dpatch. "darcs apply" it under libraries/base.
In addition, base-library.dpatch masks out some additional library code
and can be "darcs apply" it under libraries/base. It contains implementations
of GHC.Float code that are ***very likely buggy***! This code is mainly
meant for demonstrating what you can do, not for generating ext-core code
that you can execute without substantial additional work. Finally,
download the integer-simple library from:
and "darcs apply" the patch in this directory called integer-simple-library.dpatch
under libraries/integer-simple.

Once you've compiled all the libraries to Core, installed the Core Linker, and
generated an example file from it -- say, hello_out.hcr -- you can try running
the checker and interpreter.

To do that, build the example Driver program (included in this directory) with:
  ghc -package extcore Driver.hs -o Driver
and then:
  ./Driver hello_out.hcr

Of course, you can also import Language.Core.ParsecParser, Language.Core.Check,
Language.Core.Interp, etc. from your own programs.

Tested most recently with GHC 6.10.4.

==== Bugs? ====

Probably. Please direct questions or bug reports both to:
Tim Chevalier <chevalier@alum.wellesley.edu>
and to

==== Notes ====
[Warning: the following notes may be out of date, as of September 2009.]

The checker should work on most programs. Bugs (and infelicities) 
I'm aware of:

   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.

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

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.