Remove binary >= 0.7 constraint
Closed this issue · 6 comments
GHC 7.6 uses binary-0.5.x, so constraining to binary >= 0.7 has the rough effect of making this package only work with GHC 7.8. Since 7.8 has only been out for a few months, it seems way to soon to be imposing this restriction.
Yes, I've noticed that recently myself. Unfortunately, it's not easy --
it was a big API change in binary. I'd happily accept a compatibility
module patch.
+++ Doug Beardsley [Nov 07 14 13:52 ]:
GHC 7.6 uses binary-0.5.x, so constraining to binary >= 0.7 has the rough effect of making this package only work with GHC 7.8. Since 7.8 has only been out for a few months, it seems way to soon to be imposing this restriction.
Reply to this email directly or view it on GitHub:
#20
I see a commit where I removed some conditional compilation -- let me
see if I can put it back...
+++ Doug Beardsley [Nov 07 14 13:52 ]:
GHC 7.6 uses binary-0.5.x, so constraining to binary >= 0.7 has the rough effect of making this package only work with GHC 7.8. Since 7.8 has only been out for a few months, it seems way to soon to be imposing this restriction.
Reply to this email directly or view it on GitHub:
#20
OK, I remember the issue now. binary 0.5.x just calls "error" when a
parser fails, and there's no way to catch this in pure code. In
later versions (starting 0.6.4 I think) they provided functions like
runGetOrFail and decodeOrFail, which allowed me to export
the much safer function toArchiveOrFail. But I didn't see any way
to provide this function using binary 0.5.x, so I just required
0.7.
IF you see a way around this, let me know.
I believe it would be bad practice to make the API conditional on the
binary version, so if I export toArchiveOrFail at all, I need to provide
it for older versions of binary too.
I suppose I could "fake it" by defining (for binary 0.5.x)
toArchiveOrFail bs = Right <$> toArchive bs
but that seems very misleading -- what looks like a function that
handles exceptions will never return a Left value, but will raise
an exception instead.
Heh, even before I got to the bottom of your comment I was already thinking of that Right <$> ... solution. I agree with you that making your API conditional is probably a bad thing. Since this binary change is so recent, I think it's worth adding your faked definition inside some CPP. Then make prominent mention of the caveat in the haddock comment and I think you've covered your bases pretty well.
OK, it's ugly, but I'll go for it. I'll release a version
after confirming that travis builds pass.
+++ Doug Beardsley [Nov 07 14 18:52 ]:
Heh, even before I got to the bottom of your comment I was already
thinking of that Right <$> ... solution. I agree with you that making
your API conditional is probably a bad thing. Since this binary change
is so recent, I think it's worth adding your faked definition inside
some CPP. Then make prominent mention of the caveat in the haddock
comment and I think you've covered your bases pretty well.—
Reply to this email directly or [1]view it on GitHub.References
Awesome, thank you!