grin-compiler/ghc-grin

GRIN backend for GHC

ghc-grin's Issues

Can the external core be fed back into GHC?

One thing people sometimes want is to generate files of GHC’s bytecode. That can make for faster recompilation and even a way to build an “interpreted” exe, both of these could yield much faster dev cycles when the project is large and build times are more painful than runtime. On a project with 1000 modules and lots of TH, that recompiling of bytecode can hurt.

I’m wondering whether one could generate external STG when in GHC’s Interpreted linker mode.

Your external-stg looks like it goes in both directions: stg -> external stg and back. Are there any pitfalls/caveats to its current implementation?

I’m aware that its speed won’t be good because it’s using the binary package, but that’s easily swapped out for something more efficient.

lambda-grin: does not build against current grin without patching, then fails at runtime

Building: Lambda.Pretty tries to use the defunct isPrimName. It's not clear to me how best to replace it with isExternalName, but it looks like pretty might want a worker function which holds onto the exts it sees so they are in scope when we need them. The code does not appear critical, so for now I've just commented out imports of isPrimName and made the change:

@@ -32,7 +32,7 @@ instance Pretty Exp where
       ProgramF exts defs  -> vcat (prettyExternals exts : map pretty defs)
       DefF name args exp  -> hsep (pretty name : map pretty args) <+> text "=" <$$> indent 2 (pretty exp) <> line
       -- Exp
-      AppF name args      -> hsep (((if isPrimName name then dullyellow else cyan) $ pretty name) : text "@" : map pretty args)
+      AppF name args      -> hsep (pretty name : text "@" : map pretty args)
       CaseF atom alts     -> keyword "case" <+> pretty atom <+> keyword "of" <$$> indent 2 (vsep (map pretty alts))
       LetF binds exp      -> keyword "let"    <+> align (vsep (map prettyBind binds)) <$$> pretty exp
       LetRecF binds exp   -> keyword "letrec" <+> align (vsep (map prettyBind binds)) <$$> pretty exp

Runtime: after building the above with nix, I tried to generate grin from one of the test files and got a strange error:

«nix-shell» {ghc-grin/lambda-grin} $> result/bin/lambda-grin test/circular.lam -o circular.grin
lambda-grin: Data.Binary.Get.runGet at position 1: Unknown encoding for constructor
CallStack (from HasCallStack):
error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get

Using cabal new-run to build and run the binary gives the same error:

«nix-shell» {ghc-grin/lambda-grin} $> cabal new-run lambda-grin -- test/circular.lam -o circular.grin
Up to date
lambda-grin: Data.Binary.Get.runGet at position 1: Unknown encoding for constructor
CallStack (from HasCallStack):
error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get

GHC to GRIN?

Is there currently an ability to generate GRIN representation for an input Haskell program?

At the moment the structure of repositories seems to be pretty unclear. Am I right, that https://github.com/grin-compiler/grin contains only those parts of grin that operate only with GRIN representation and does not have any frontends support? And what is the purpose of this repository? Most of the modules inside stack.yaml are commented out and if I uncomment some of them stack build does not succeed

The thing that I wanted to do is to try to utilize GRIN as an intermediate representation for hardware generation, but my input programs are in Haskell (and are optimized first using Haskell-related stuff). Is there any workflow how one would achieve this?

How can I try this out?

The README here and in https://github.com/grin-tech/grin have left me a little unclear about how to go about trying out this project, and how all the pieces fit together. Even very brief instructions for building a ghc that has the GRIN backend would be really helpful.

And is there a website or blog where you talk about this work? Thanks!

Why STG instead of Core?

I see in the README that at some point you changed from compiling from Core to compiling from STG. I'm curious why — from a quick scan of the paper's abstract GRIN seems to have a similar purpose to STG.