The extcore package

[Tags: bsd3, library]

Libraries for processing GHC Core


[Skip to ReadMe]

Properties

Versions0.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 logNone available
Dependenciesarray, base (==4.*), bytestring, containers, directory, filepath, mtl, parsec, pretty, syb [details]
LicenseBSD3
AuthorAndrew Tolmach, Tim Chevalier, The GHC Team
MaintainerTim Chevalier <chevalier@alum.wellesley.edu>
Stabilityalpha
CategoryLanguage
UploadedWed May 12 22:13:24 UTC 2010 by TimChevalier
DistributionsNixOS:1.0.2
Downloads2020 total (58 in last 30 days)
Votes
0 []
StatusDocs not available [build log]
All reported builds failed as of 2015-05-27 [all 2 reports]

Modules

Downloads

Maintainers' corner

For package maintainers and hackage trustees

Readme for extcore-0.6

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:
http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf

==== 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:
http://hackage.haskell.org/package/linkcore

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
glasgow-haskell-users@haskell.org

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