Hi Tim,

About using GHC as a library module, have you see the ongoing work on "native metaprogramming" in GHC at

https://ghc.haskell.org/trac/ghc/wiki/NativeMetaprogramming

and a child project at

https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow

There, online code generation is not of the highest priority, rather we are trying to open up the compiler from top to down:

making available GHC's AST and then the parser and the typechecker have priority over the other functionalities down the pipeline (like the code generator).

> If any one wanted to help with this, that would be great.

I am interested to hear more about the approach you have in mind, and would be happy to help.

Yours,

Shayan

On Fri, Nov 17, 2017 at 6:05 PM, Tim Sheard <sheard@pdx.edu> wrote:

After many years of hoping someone else would do this, I would like to
make GHC into a true multi-stage programming language. Here is how I
thought I might approach this.

1) Use the GHC as a library module.
2) Use the LLVM backend.

I have no experience with either of these tools.
Lets start simple, How would I write functions like

compile :: String -> IO PtrToLLVMCode -- where the string is a small Haskell program.
llvmCompile :: PtrToLLVMCode -> IO PtrToMachineCode
jumpTo:: PtrToMachineCode -> IO ans -- where ans is the "type" of the string.

Any thoughts on how to get started? What papers to read, examples to look at?

I'd love to move to some more disciplined input type, a sort of (mono) typed program
representation (with similar complexity) to Template Haskell Exp type.

where (Exp t) is a data structure representing a Haskell program of type t.

All offers of advice accepted. I'm trying to get started soon, and good advice
about what to avoid is especially welcome. If any one wanted to help with this,
that would be great.

Tim Sheard

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs