Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compat: Expose DNonEmpty across more versions of base #118

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

414owen
Copy link
Contributor

@414owen 414owen commented Dec 26, 2023

  • Add CPP guards around some instances
  • Remove some conditional cabal
  • Use NonEmpty-based fold functions directly
  • Add tests for fold instance
  • Add handwritten Read instance
  • Disable DNonEmpty test suite on base <4.9.0

Functions that convert to/from NonEmpty are gone, but everything that you strictly speaking need to use DNonEmpty is there.

* Create a single list of quickcheck properties
* Test the result of the quickcehck run
* Exit with appropriate status code
* Add CPP guards around some instances
* Remove some conditional cabal
* Use NonEmpty-based fold functions directly
* Add tests for fold instance
* Disable DNonEmpty test suite on base <4.9.0
@spl
Copy link
Owner

spl commented Feb 17, 2024

Thanks for taking the time to do this, but I'm a bit unsure about the motivation or need for this change. Could you be more explicit about what is gained by doing this? What were you unable to do before this change?

@414owen
Copy link
Contributor Author

414owen commented Feb 18, 2024

Sure, I have a library called multi-except, which lets you applicatively build up multiple errors. It exports them as a NonEmpty, and uses a non-empty dlist internally.

I'm a big believer in libraries casting as wide a compatibility net as possible, as it really helps avoid dependency hell. This is especially true of such universal (and useful) libraries as dlist.

Multi-except currently supports ghc >=7.0.4, with base being its only dependency. I did this by using my own inline implementation of non-empty dlists. This seems acceptable, because it's such a small amount of code, but at the same time, I don't think the functor instance is optimal.

I would prefer to use the implementation from the dlist package, so that I get the advantages of all the thought put into this library, but I don't want to sacrifice compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants