filepath
filepath copied to clipboard
haskell
Haddock "source" links are broken since the `OsPath` transition
Before: https://hackage.haskell.org/package/filepath-1.4.2.2/docs/src/System.FilePath.Posix.html#takeFileName
After: https://hackage.haskell.org/package/filepath-1.4.100.3/docs/src/System.FilePath.Posix.html#takeFileName
@hasufell I think I understand the underlying motivation, and I am generally sympathetic to DRYing things up, this is why so far I refrained from reporting this as a bug.
However, I think that this puts us into an unfortunate situation:
-
Most importantly, code is far more often read than written. This is why personally I would not be willing to sacrifice readability for DRYness.
-
But also, CPP is a real challenge for tooling. This does not only affect you if you work on a package that makes heavy use of CPP. It also makes it difficult to e.g. implement a "go to definition" that works across packages. By my book less CPP is always a good thing.
-
For me, the final straw is that it's not only
filepath, but that I see a spreading pattern here (directory,file-io, ...).
There's supposedly a way without CPP: https://discourse.haskell.org/t/pre-ghc-proposal-instantiate-backpack-signatures-when-importing/6739/17
Backpack would not be my first choice.
This does not require backpack. See the comment:
If we’re spitballing alternative methods of achieving backpack…
You could possibly also use convenience 3 internal libraries, make them share the same source module that you want to have multiple implementations, but each import their parameter (types, implementations) from a module in isolated source directories. To instantiate them you’d use PackageImports. No CPP required (although could be used).
That would serve the local project case, but wouldn’t serve the open world case that backpack does.
That sounds much better. But at least for file-io it could be even simpler. PR coming.
If you want to do the same for filepath, feel free... but it's going to be a little more work.