This section describes other program(s) which we distribute, that help with the Great Haskell Programming Task.
Andy Gill and Simon Marlow have written a parser-generator for Haskell, called happy. Happy is to Haskell what Yacc is to C.
You can get happy from the Happy Homepage.
Happy is at its shining best when compiled by GHC.
The hsc2hs command can be used to automate some parts of the process of writing Haskell bindings to C code. It reads an almost-Haskell source with embedded special constructs, and outputs a real Haskell file with these constructs processed, based on information taken from some C headers. The extra constructs deal with accessing C data from Haskell.
It may also output a C file which contains additional C functions to be linked into the program, together with a C header that gets included into the C code to which the Haskell module will be compiled (when compiled via C) and into the C file. These two files are created when the #def construct is used (see below).
Actually hsc2hs does not output the Haskell file directly. It creates a C program that includes the headers, gets automatically compiled and run. That program outputs the Haskell code.
In the following, “Haskell file” is the main output (usually a .hs file), “compiled Haskell file” is the Haskell file after ghc has compiled it to C (i.e. a .hc file), “C program” is the program that outputs the Haskell file, “C file” is the optionally generated C file, and “C header” is its header file.
hsc2hs takes input files as arguments, and flags that modify its behavior:
The input file should end with .hsc (it should be plain Haskell source only; literate Haskell is not supported at the moment). Output files by default get names with the .hsc suffix replaced:
.hs | Haskell file |
_hsc.h | C header |
_hsc.c | C file |
The C program is compiled using the Haskell compiler. This provides the include path to HsFFI.h which is automatically included into the C program.
All special processing is triggered by the # operator. To output a literal #, write it twice: ##. Inside string literals and comments # characters are not processed.
A # is followed by optional spaces and tabs, an alphanumeric keyword that describes the kind of processing, and its arguments. Arguments look like C expressions separated by commas (they are not written inside parens). They extend up to the nearest unmatched ), ] or }, or to the end of line if it occurs outside any () [] {} '' "" /**/ and is not preceded by a backslash. Backslash-newline pairs are stripped.
In addition #{stuff} is equivalent to #stuff except that it’s self-delimited and thus needs not to be placed at the end of line or in some brackets.
Meanings of specific keywords:
#const, #type, #peek, #poke and #ptr are not hardwired into the hsc2hs, but are defined in a C template that is included in the C program: template-hsc.h. Custom constructs and templates can be used too. Any #-construct with unknown key is expected to be handled by a C template.
A C template should define a macro or function with name prefixed by hsc_ that handles the construct by emitting the expansion to stdout. See template-hsc.h for examples.
Such macros can also be defined directly in the source. They are useful for making a #let-like macro whose expansion uses other #let macros. Plain #let prepends hsc_ to the macro name and wraps the definition in a printf call.
hsc2hs normally operates by creating, compiling, and running a C program. That approach doesn’t work when cross-compiling — in this case, the C compiler’s generates code for the target machine, not the host machine. For this situation, there’s a special mode hsc2hs --cross-compile which can generate the .hs by extracting information from compilations only — specifically, whether or not compilation fails.
Only a subset of .hsc syntax is supported by --cross-compile. The following are unsupported: