{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia4h6nuswju2krzudijm6szombrmmn3oeaotqajhsk43zvdxhz7au",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mk3a3og3nqo2"
  },
  "path": "/t/modern-haskell-c-translation-approaches/13941#post_6",
  "publishedAt": "2026-04-22T09:08:13.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Hello everyone,\n\nThanks a lot for all the detailed answers — I really appreciate the insights.\n\nTo clarify my use case a bit more: my goal is not portability per se, but rather to use C as an intermediate representation step in a toolchain. In particular, I am interested in leveraging existing C-based obfuscation tooling (e.g. Tigress) as part of a pipeline for transforming Haskell programs. After that, I would like to further lower the result to LLVM IR and analyze it, especially to reconstruct data-dependency graphs using LLVM passes.\n\nI did try MicroHs as suggested, but the generated C code appears to represent the Haskell runtime rather than the original program structure. It essentially produces a low-level runtime-like representation (large table), which makes it difficult to recover meaningful data-dependency information at the LLVM level.\n\nRegarding NASA’s Copilot, I understand it can compile a subset of Haskell-like stream programs to C99, but it seems to target a very specific domain (embedded, real-time stream processing), so it would not be applicable to general-purpose modern Haskell code.\n\nThanks again for all the suggestions — they were very helpful in clarifying the landscape of existing approaches.\n\nMarkus",
  "title": "Modern Haskell → C translation approaches?"
}