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