TH doesn't allow generating CTYPE pragma

[phadej]

There are simply no entry for that in AST:

Prelude Language.Haskell.TH> [d| newtype {-# CTYPE "int" #-} Bar = Bar Int |] >>= print
[NewtypeD [] Bar_0 [] Nothing (NormalC Bar_1 [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)]) []]

---

I feel that is a show stopper.

FWIW, it's not possible with haskell-src-exts either.

[phadej]

I opened upstream issue https://gitlab.haskell.org/ghc/ghc/-/issues/25223, but we have to figure out what to do in the meantime. (I guess we simply wont' use CApiFFI for quite a while).

[edsko]

Given both this problem as well as your reluctance to use haskell-src-exts (#123), perhaps we should have our own abstraction for Haskell code after all (@FinleyMcIlwaine had one in his prototype implementation, but we decided in the end that it wasn't worth it). It should then be easy to generate both Haskell source as well as TH splices from this, although I guess if TH doesn't support this, the tool in TH mode would not be quite fully functional, which is unfortunate but perhaps unavoidable then?

[phadej]

perhaps we should have our own abstraction for Haskell code after all

I have thought about this, and I think it's worth it. We'd include only features we truly need. haskell-src-meta goes from "anything possible to TH", which is a lot to do, and they even say

The translation from haskell-src-exts abstract syntax to template-haskell abstract syntax isn't 100% complete yet.

Until we start working on high-level API generation, we don't even generate a lot of syntax. Not that high-level API would need all the GHC Haskell whistles either.

[edsko]

Ok, then let's do that and introduce our own Haskell abstraction.

[edsko]

One advantage of our own representation is that we can be more typed; rather than just specifying "class instance", we can say "this is a storable instance", and provide exactly what we need: the AST would be more typed. I'll start on this now.