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, ...).
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, ...).