deepseq
deepseq copied to clipboard
haskell
NFData instances for unboxed arrays from array
NFData instances could be provided for UArray, STUArray and IOUArray from the array package: https://hackage.haskell.org/package/array
PS: I find it a little odd that deepseq depends on array and has to provide these, rather than the other way around.
PS: I find it a little odd that
deepseqdepends onarrayand has to provide these, rather than the other way around.
It should rather be other way around indeed.
I looked into this a bit, and it seems there are two ways we can go about it.
A. deepseq provides the instances
This is simple enough. I can make a PR for it.
B. Reverse the deepseq->array dependency
It turns out that the Array type is defined not in array, but in base's GHC.Arr. So deepseq never required a dependency on array in the first place. The steps here are:
deepseqdrops the dependency onarrayand providesNFDataforArrayusingGHC.Arr. This is released as versiondeepseq-x.array-yprovidesNFDatainstances for unboxed arrays by taking a dependency ondeepseq >= x. Users ofarray >= yget the instances.
Sidenote: I found that there was a plan to reverse deepseq->containers and deepseq->array dependencies in GHC #5468, but they stopped at containers due to undocumented reasons.
What do you think?
Given that deepseq is a dependency of template-haskell, the former is practically non-reinstallable and such are its dependencies as well, including array. I think "B. Reverse the deepseq->array dependency" would be most beneficial.
The steps here are:
I think the same could be achieved with automatic Cabal flags: a dependency cycle should be automatically rejected by Cabal solver, forcing flipping a flag. But this requires testing, and being boot packages is likely to complicate things.
Could you explain what you mean be automatic Cabal flags? I didn't get that, but then again I'm not too familiar with Cabal stuff.
As I see it, for B the only thing deepseq needs to do is simply drop the array dependency. Nothing would be lost with this. Further changes are required only to add new NFData instances.
Ah, that's even simpler then. I guess the only relevant part of my comment is that array-y does not even need to demand deepseq >= x, because Cabal solver would imply such bound automatically to avoid circular dependencies.
@mixphix would you please provide your opinion on this?
If we're good with dropping the array dependency, I can make the PR here, then take up the rest of the work on the array side.
Dropping the array dependency is fine by me. Thanks for volunteering to do that!
@mixphix thanks for a quick turnaround!
Did I miss a breaking change since 1.5.0.0? If there were none, could it be released as 1.5.1.0 (and 1.6.0.0 marked as deprecated so that it does not pop up in build plans, see how it was done for binary)? Sorry for asking to do more work, but upgrading version bounds to allow deepseq-1.6.0.0 across the ecosystem is somewhat expensive.
My apologies, I should have reviewed the PVP before releasing. I was under the impression that dropping a dependency required a major version bump. I'll re-release this as 1.5.1.0 and mark deepseq-1.6.0.0 as deprecated. Any breaking changes to be released in the next version will be released as 1.6.0.1.