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
Dependencies base (>=3 && <=4), 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 Sep 27 23:05:49 UTC 2009
Distributions NixOS:1.0.2
Downloads 4984 total (40 in the last 30 days)
Rating 2.0 (votes: 1) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs not available [build log]
All reported builds failed as of 2016-12-31 [all 6 reports]
Hackage Matrix CI


  • Language
    • Core
      • Language.Core.Check
      • Language.Core.Core
      • Language.Core.CoreUtils
      • Language.Core.ElimDeadCode
      • Language.Core.Encoding
      • Language.Core.Env
      • Language.Core.Interp
      • Language.Core.Merge
      • Language.Core.ParsecParser
      • Language.Core.Prep
      • Language.Core.Prims
      • Language.Core.Printer


Maintainer's Corner

For package maintainers and hackage trustees

Readme for extcore-0.2

[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.

[TODO: where do you get the Core Linker?]

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 a small library patch that circumvents 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.

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.