haskell / haskell/cabal

Document the interaction between Backpack and Template Haskell

Open
#7,353 2 comments 1 reaction 0 assignees View on GitHub
Cabal: Backpack documentation
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

Perhaps the [Backpack section of the user guide](https://cabal.readthedocs.io/en/latest/cabal-package.html#backpack) could devote a paragraph or subsection to explaining the interaction between indefinite libraries and TH code.

I've found that splicing TH code from libraries that are still indefinite (that is: libraries that have [module signatures](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/separate_compilation.html#module-signatures) still unfilled) causes errors like

```
ghc: ^^ Could not load 'lesson9zmtemplatezmhaskellzm1zi0zi0zi0zminplacezmcorezmAfo5JIVDJVcCScFF1FkCSzz_CoreziTH_makeIdFunc_closure', dependency unresolved. See top entry above.
GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
lesson9zmtemplatezmhaskellzm1zi0zi0zi0zminplacezmcorezmAfo5JIVDJVcCScFF1FkCSzz_CoreziTH_makeIdFunc_closure
```

I wrote a longer description of the problem [here](https://github.com/danidiaz/really-small-backpack-example/tree/master/lesson9-template-haskell).

I'm not 100% sure, but the problem might be that indefinite libraries get typecheked, but not compiled down to object code (they can't be, because they have "holes" in the form of module signatures).

Therefore, when splicing the code, there's no actual TH code to run! So this is not a bug, but an insurmountable limitation of Backpack (although the errors could be better).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.