Data.Graph.SCC: store mutually reachable vertices in a non-empty list #953
Conversation
|
GHC 8.0 build fails because of the lack of
|
Bodigrim
force-pushed
the
scc
branch
3 times, most recently
from
75de925
to
a52f95b
Compare
|
There seem to be two issues remaining:
I don't really like the primed name, but I'm willing to go along with it if no one can come up with anything better. For the CI failure, I'm okay with dropping support for 8.0, but that will definitely need its own commit, and should probably be a separate PR merged before this one. |
|
|
Could you please rebase this? |
They're all horrible (and my own attempts were worse), but I think I dislike |
|
@treeowl all ready now. Shall I update changelog as well? |
|
Yes, please! |
|
Changelog updated. |
|
Thanks!!! |
| deriving ( Eq -- ^ @since 0.5.9 | ||
| , Show -- ^ @since 0.5.9 | ||
| , Read -- ^ @since 0.5.9 | ||
| ) | ||
|
|
||
| -- | Partial pattern synonym for backward compatibility with @containers < 0.7@. | ||
| pattern CyclicSCC :: [vertex] -> SCC vertex |
There was a problem hiding this comment.
Doesn't the pattern synonym definition also need to be guarded by #ifdef __GLASGOW_HASKELL__ ?
I'm always confused by the portability story. Tangentially related, how do we even test this given CI only uses ghc?
There was a problem hiding this comment.
Yes it does. The portability story kind of sucks right now. The main goal as I see it is to make sure it won't be too big a pain to add support for a future Report-style Haskell (Purescript, sadly, is just a bit too far away to be a practical target for this). I think we should stop using __GLASGOW_HASKELL__ directly and instead use a few of our own macros. We should have a build job that pretends were not on GHC; getting that to do testing right will take a bit of fussing, but it's probably doable?
…pty list (haskell#953)" This reverts commit c8a24e8.
As discussed in #952.
CC @meooow25