Hello, I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module. The library was originally written by Andrew Tolmach and was part of the GHC distribution. After becoming its maintainer, about a year ago I moved the library to Hackage. Since in the past year, the library has acquired some users but has received no fatal bug reports, I thought it was time for a 1.0 release. You might be interested in using this library if you're a compiler or tool writer who wants to write a tool that processes the output of GHC's front-end and simplifier -- that is, code in the Core intermediate language, a typed functional language in which many of Haskell's features have been desugared into a polymorphically typed lambda-calculus (extended with type coercions, as are necessary to support type system features such as GADTs). Such tools might include alternative back-ends or new program transformations. Using the extcore library allows tool writers to experiment with implementing new compiler features without modifying GHC itself. While the GHC API is also a route to adding new stages to the GHC pipeline, using extcore has the advantage that External Core is well-specified (read on) and less subject to change than GHC's internal Core format. The library has been tested on External Core produced by GHC 6.10.* and GHC 6.12.*. It has not yet been tested on External Core produced by GHC 7.*. Documentation for the External Core format itself lives at http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf - but documentation for the library is limited, and I would welcome documentation or other patches. Currently the best source of documentation for the library is the README file, found in the distribution. To get the distribution, please visit http://hackage.haskell.org/package/extcore or cabal install extcore. Please direct replies to glasgow-haskell-users@haskell.org, with me CCed. Please make sure not to reply to haskell@haskell.org. Cheers, Tim Chevalier -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings
On Thu, Jan 13, 2011 at 11:45 AM, Tim Chevalier
Hello,
I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module. The library was originally written by Andrew Tolmach and was part of the GHC distribution. After becoming its maintainer, about a year ago I moved the library to Hackage. Since in the past year, the library has acquired some users but has received no fatal bug reports, I thought it was time for a 1.0 release.
You might be interested in using this library if you're a compiler or tool writer who wants to write a tool that processes the output of GHC's front-end and simplifier -- that is, code in the Core intermediate language, a typed functional language in which many of Haskell's features have been desugared into a polymorphically typed lambda-calculus (extended with type coercions, as are necessary to support type system features such as GADTs). Such tools might include alternative back-ends or new program transformations. Using the extcore library allows tool writers to experiment with implementing new compiler features without modifying GHC itself. While the GHC API is also a route to adding new stages to the GHC pipeline, using extcore has the advantage that External Core is well-specified (read on) and less subject to change than GHC's internal Core format. The library has been tested on External Core produced by GHC 6.10.* and GHC 6.12.*. It has not yet been tested on External Core produced by GHC 7.*.
Documentation for the External Core format itself lives at http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf - but
Oops, that'll learn me not to check links before I send email. The correct URL for the documentation is: http://www.haskell.org/ghc/docs/latest/core.pdf
documentation for the library is limited, and I would welcome documentation or other patches. Currently the best source of documentation for the library is the README file, found in the distribution. To get the distribution, please visit http://hackage.haskell.org/package/extcore or cabal install extcore.
Please direct replies to glasgow-haskell-users@haskell.org, with me CCed. Please make sure not to reply to haskell@haskell.org.
Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings
On 01/13/2011 10:45 PM, Tim Chevalier wrote:
Hello,
I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module.
May be a stupid quesion, but does interpreter allow reasonably easy way to expose some haskell functions and data types to interpreted code as 'primitives' ? such an interpreter may be yet another scripting language, yet quite verbose one.
On Sun, Jan 16, 2011 at 9:32 AM, Permjacov Evgeniy
On 01/13/2011 10:45 PM, Tim Chevalier wrote:
Hello,
I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module.
May be a stupid quesion, but does interpreter allow reasonably easy way to expose some haskell functions and data types to interpreted code as 'primitives' ? such an interpreter may be yet another scripting language, yet quite verbose one.
Maybe? I'm not sure I understand your question, but take a look at the evalPrimop function in Language/Core/Interp.hs and see if that answers your question. I have to admit that the interpreter is the most bit-rotted part of the External Core tools and its main function right now is to give an operational semantics for Core rather than to actually execute Core programs. I'd welcome any help with that! Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings
participants (2)
-
Permjacov Evgeniy -
Tim Chevalier