any future plan?

[fonghou]

Hi @lexi-lambda, haven't seen any updates since you put out no-monad-control branch. Just curious what's the future plan on this project. Sorry to ask if you are busy on something else.

[lexi-lambda]

Hi there. Yes, I am still working on this, but I unfortunately simply haven’t had the time to focus on it for the past month or so. However, I expect to have time again to spare for this project soon, so hopefully there will be visible progress again shortly.

To explain the current situation a little more: since I started this project, I have done a lot of learning. Specifically, I have learned the following broad points:

1. I believe the semantics provided for scoped operations in mtl, transformers, fused-effects, and polysemy is fundamentally unhelpful, and I think the arguments made for it in Effect Handlers in Scope are spurious. I have come up with an alternative semantics based on delimited control that I believe to be significantly more predictable, but implementing it in Haskell is tricky for at least two reasons.

2. The first of those reasons is IO exceptions, synchronous and asynchronous alike. It is very clear what the semantics ought to be here, and other implementations such as the Eff language even provide them, but Haskell is more complicated due to laziness, and the primitives exposed by the RTS are limited. I have not yet figured out the right solution here, or if there even is one.

3. The second of those reasons is performance. The longer I have worked on this, the more I believe the performance of mtl itself is unacceptably poor. This might sound strange, as mtl is often considered to be the gold standard, but I think this is actually a widespread misunderstanding: transformers is fast, and mtl when used against concrete transformers is fast, too. But using mtl as an effect system by writing polymorphic functions with mtl typeclass constraints is not fast; in fact it is rather slow.

   I don’t think it has to be this way. There is an efficient implementation here—maybe not as efficient as concrete transformers, but closer than mtl. I also believe I understand what that implementation ought to look like in Haskell in broad strokes, but the devil is in the details, and more work is needed.

When I first created this repository, it was my hope that the research work on eff was mostly done, and the rest would just be engineering. Sadly, while implementing NonDet, I discovered the first point above, and the rest followed from there. So the good news is that there is still forward progress, and that progress is, I think, meaningful. The bad news is that there is still much more work to be done.

[smunix]

fyi, I've been using eff in one of my application for over a month now and I truly like it. @lexi-lambda eff is the first effectul library that I've been able to put to use effectively. I'm looking forward to a released version of this library.

[lexi-lambda]

@smunix I appreciate the positivity! However, I’m afraid I must admit that I expect the API of this library to completely change before it is released. So I wouldn’t recommend writing any code against it right now unless you’re prepared to make significant changes in the future.

[lexi-lambda]

I have now merged the rewrite to master. Currently, I don’t expect the rewrite to be very useful to people—it depends on a fork of GHC—but I’m in the process of getting that change to a place where I can submit a GHC proposal, so eventually it will get there. I’m going to close this issue, and I’ll announce elsewhere as progress continues.