search

int-index / ether

Monad Transformers and Classes
https://int-index.github.io/ether/
BSD 3-Clause "New" or "Revised" License
78 stars 7 forks source link

Incompatible with base-4.11 #39

Closed nomeata closed 6 years ago

nomeata commented 6 years ago

I was about to try ether, but I am using base-4.11, so it does not yet seem to be available to me.

int-index commented 6 years ago

GHC doesn't know how to optimize ether code properly, generating numerous useless instance specializations. It causes memory consumption at least quadratic in the amount of transformer layers.

At work we were hitting 64 GiB memory limit on our build machines, due to use of ether. It could only be solved by -fno-specialize (I don't remember the exact flag name), which is very unsatisfactory.

You can observe this even when compiling the ether test suite .

Because of this, I no longer use ether and don't actively maintain it. So you're welcome to make it work with newer base and I'll upload a new version on Hackage, but your time will be better spent with a different effect system :)

nomeata commented 6 years ago

Thanks for the warning. Maybe you want to mark the package as deprecated on hackage? You can do that without uploading a new package, on this link: http://hackage.haskell.org/package/ether/maintain

int-index commented 6 years ago

Alright, I marked it as deprecated. Thanks for the suggestion.

4e6 commented 6 years ago

@int-index It seems that you are talking about #14338. The issue was fixed for the test example we provided, and currently, I'm migrating our project to 8.4 to do the full-scale test. Can you confirm that #14338 did not solve the compilation issue for you?

4e6 commented 6 years ago

@int-index I've just finished migration to 8.4. New ghc-8.4.1 uses ~4GB of RAM, compared to ~12GB with ghc-8.2.2. It's a significant improvement.

The regression that I linked was not ether-specific, servant and hreader, for example, were also affected. You sure you wish to abandon ether? Even if it adds some extra work for the compiler, and probably not suitable for very large projects, it still can be useful for small and medium ones.

int-index commented 6 years ago

Thanks for investigating this @4e6, and it's good news that with newer GHC using ether at scale is possible!

However, I'm still unable to guarantee that I will allocate enough time to its maintenance. If you'd like to become a maintainer of ether I'll grant you commit rights on GitHub and upload rights on Hackage.

4e6 commented 6 years ago

@int-index thanks for the credit, but I don't feel I should be a maintainer, mainly because I don't have any ideas on further development. Still, it's a great project, and I learned Haskell a lot by studying the implementation details. Someone will pick it up.

4e6 commented 6 years ago

Regarding the issue. Please add the revision with updated bounds:

base >=4.9 && <4.12

Nothing else needs to be changed. It already compiles with ghc-8.4.1; tested with nightly-2018-04-05 Stackage resolver