Should we add line numbers and column ranges

[KommuSoft]

This makes it more convenient to let software "talk" in a uniform format.

As separator between the file and line number, a colon (:) is often used, this is the same for a line number and a column number. For a range between two columns, we can use an en dash (–), so then we got as formats:

System/FilePath.hs
System/FilePath.hs:14
System/FilePath.hs:14:25
System/FilePath.hs:14:13–25

This thus introduces three extra data types, one that adds a line number, and two that depend on the former to add either a single column, or a column range.

[hasufell]

Sorry, what are you talking about?

[hasufell]

I think I get it now. But:

1. this is not a very common cross-platform convention or part of the windows documentation or the posix standard
2. this can easily be implemented in another library that builds on top of filepath
3. I don't see evidence that many packages on hackage need this... filepath is a core/boot library and very conservative about radical changes/additions that are not proven to be useful yet
4. I'm not even sure how exactly the API would look like, how you resolve parsing ambiguity etc.

[hasufell]

maybe some CLC members want to chime in: @Bodigrim

[KommuSoft]

A small package on top seems like a good solution! This is more to fix the fact that a lot of applications with parsing, etc. don't seem to have a uniform way to specify a token location. This makes it harder to then parse the location back in a generic way, for example in some sort of IDE.

[hasufell]

Maybe, but I don't see how that's the job of a filepath library. Especially since there are possibly many different designs.