Feature: TH to generate freer monadic actions

[isovector]

This PR adds Control.Monad.Freer.TH, which contains TH functions capable of generating type signatures and declarations for lifting GADT constructors into Eff.

Non-GADT datatypes are not supported, although this isn't a particularly difficult thing to add support for later.

Closes #16

[trskop]

I've rebased the PR to current master, which is a good starting point for us to being able to accept it.

This will probably won't be able to compile on older GHC versions due to library incompatibilities. Hopefully at least GHC 8.0.* will be able to compile it.

Next steps:

• Resolve library incompatibilities.
• Write few tests for it.
• Enhance documentation with few more usage examples, and add at least one into examples/.

[isovector]

What do you mean by resolving library incompatibilities? CPP to hide this from old versions of template-haskell?

I'm by no means a TH expert, but what would tests for this stuff look like? Just "write a GADT, use TH to make actions, then then write tests using those actions", or do you have something more in mind?

[xkollar]

@isovector: see CI results...

[isovector]

@xkollar thanks! missed that somehow.

Looks like fundamentally template-haskell doesn't provide access to language extensions until 2.11.0.0, so there is no "real" way of solving this issue for the failing cases. What's the correct solution moving forwards? Bumping the TH lower bounds and hiding this module behind a cabal flag?

[trskop]

I think that checking if FlexibleContexts extension is enabled provides better error message than what GHC would print out normally. However, that doesn't mean we should disable this functionality entirely on older GHCs (i.e. older template-haskell).

[trskop]

Guys (in non-gender specific way), what do you think about the names makeFreer, and makeFreer_? Do we have better alternatives? IMHO, they aren't very descriptive in regards to their functionality.

[isovector]

The problem is unfortunately deeper than just the FlexibleContexts check -- also the GadtC constructor doesn't exist until 2.11.0.0, without which none of this works whatsoever :)

re: makeFreer -- the naming is intentionally analogous to https://hackage.haskell.org/package/free-4.12.4/docs/Control-Monad-Free-TH.html

[trskop]

Yes, that is a problem (missing GADT support), but we also need to generalise the TH code to support standard non-GADTs. There is a non-trivial class of effects that can be created without the need to pass type equalities around. I'd rather provide some TH code for older GHCs then none. It gets really confusing when Hackage says that you have a TH module, but the compiler says otherwise.

Regarding naming convention. IMHO, it's not very convincing that it's the same naming convention as free uses. Free applicatives and monads have nothing to do with Freer Effects, and especially effect types them selves. Convention used in e.g. lens makes much more sense to me. What would you say to something like makeEffect?

[isovector]

FWIW, I'd prefer to get this merged, possibly with <2.11.0.0 CPP that fail "this module requires template-haskell-2.11.0.0 (for now)"s. This module as it stands has value, and after this week I'm not going to have much time to devote towards OSS until May. Thoughts?

[xkollar]

Regarding naming of those makeFreer functions: I find naming convention of analogous functions in free arbitrary and thus do not see a reason to follow it...

Those functions do not create effects, they just create convenience functions... I would suggest {make,mk}EffectCalls, or something...

Naming things is hard... https://martinfowler.com/bliki/TwoHardThings.html

[trskop]

If you won't mind then we could take care of it for you. It may take a few days, since we are investing our free time into this.

BTW, thanks for doing this. It really helps to have such a great feedback.

[isovector]

Feel free to carry on! It's awesome to have such active maintainers of this package :)

[isovector]

Any word on this? I'm giving a talk on freer-effects next week at bayhac, and would love to be able to say "too much boilerplate for you? fear not! there's TH to help!" :)

[xkollar]

@isovector: Currently we are little tight on time but have not forgotten about it. Sorry for the inconvenience.

[mmaz]

any chance this could be merged in before the next release? thanks!!

[ProofOfKeags]

Is this happening?

[liskin]

Nothing is happening, we should never have forked this. Sorry. :-(

[ProofOfKeags]

Is it just that they aren’t being accepted upstream or is there some other problem? On Mon, Aug 6, 2018 at 12:11 AM Tomáš Janoušek notifications@github.com wrote:

Nothing is happening, we should never have forked this. Sorry. :-(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IxpertaSolutions/freer-effects/pull/28#issuecomment-410599391, or mute the thread https://github.com/notifications/unsubscribe-auth/AD2Mc4zheMY362Ln47FEF-rxYiq3pRJuks5uN94hgaJpZM4Mhn6u .

[liskin]

@CaptJakk I'm (one of) the upstream. I am the one who forked this 2 years ago, naïvely believing we'd have the resources to keep the project alive. We have all left the company since then. I'm no longer doing anything Haskell related in my day job, and I have way too much other projects in my spare time. My former colleagues do, as far as I know, work in Haskell-related positions, but apparently none of that involves freer-effects either.

This project is dead, let's admit it. I'm sorry.

[ProofOfKeags]

Got it. Is it just freer-effects that's dead or is freer dead as well?

[liskin]

@CaptJakk freer seems dead as well, that's why we forked it then.

[isovector]

@CaptJakk try https://github.com/lexi-lambda/freer-simple