Add effectful-th package

[mmhat]

This PR adds a new package effectful-th including a TH function makeSendFunctions that generates functions for the effect operations of dynamic effects (See the OP of #20).

The test suite included just checks if the generated functions for the dynamic effects defined in effectful-core compile.

[mmhat]

@arybczak I think this one can be reviewed and merged. 🙂

[arybczak]

Thanks!

Do other packages have more tests for a bit more "weird" effect data types that can be added?

For example, I wonder if this works: polysemy-research/polysemy#339

[arybczak]

Can you replace this with TemplateHaskellQuotes?

[mmhat]

Unfortunately that is not possible. Changing that to TemplateHaskellQuotes results in:

src/Effectful/TH.hs:156:40: error:
    Operator applied to too few arguments: :>
    |
156 |       effectConstraint = [t| $(effect) :> $(varT es) |]
    |

[arybczak]

This requires getting rid of splices, but it should be possible as you can construct the AST manually. FWIW optics-th uses TemplateHaskellQuotes only. This matters for cross-compilation.

[arybczak]

Why the re-exports?

[mmhat]

I included them for slightly better ergonomics: This way one can just import Effectful.TH and is not confronted with a bunch of "... not in scope" error messages immediately.

[mmhat]

Unfortunately the current implementation does not work well with "weird" effects.
This module is build around th-abstraction - which is just too much abstraction to support these types.
In particular, both

data T1 a where
  C1 :: forall a b. T1 a

data T2 a where
  C2 :: forall b a. T2 a

are reified to something like:

DatatypeInfo { ..., datatypeVars = [KindedTV a () StarT], ..., datatypeCons = [ConstructorInfo {..., constructorVars = [KindedTV b () StarT], ...}]}

Note the order of the type variables of the explicit forall is completely lost and we cannot figure out how to construct the type applications at the call site.

I will think about a more elaborate solution using template-haskell directly.

[arybczak]

I wouldn't worry about that, it's better to use th-abstraction as that eases maintenance burden, direct template-haskell breaks too often.

[mmhat]

I wouldn't worry about that, it's better to use th-abstraction as that eases maintenance burden, direct template-haskell breaks too often.

That's why I chose it in the first place 🙂
However, the example given in polysemy-research/polysemy#339 will not work since it requires an extra type application of the ty variable and I don't know (yet) how to get this right.

I propose the following: Unless I find a clear path forward throughout the next days will push some more documentation regarding known limitations and we can merge this (I will of course address the remaining issues first). If we figure out a way to improve the module in this regard it can happen on a separate PR.

[arybczak]

I think I'll go with #60. The code is trivially ported from cleff.

[arybczak]

Superseded by #60, thanks for the work though!