Am 27.02.2017 um 01:07 schrieb Eric Mertens:

If we're going to improve the state of the file path type, it would be appropriate to first develop a package to work out the new design. Packages have already tried and failed at this, and the base package isn't the place to experiment in this space. Once this package existed and saw wide use, allowing kinks in the API to be worked out, it would then be appropriate to think about migrating base to it.

the way i understand the proposal it doesn'work that way, it's about a migration path in the face of many existing modules, not only base, that use the FilePath type synonym.

Regards, Eric

On Sun, Feb 26, 2017 at 2:43 PM Ben Franksen wrote:

...

Am 26.02.2017 um 21:58 schrieb Boespflug, Mathieu:

...

a few folks got together to propose this nearly 2 years ago:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath

Has anything become of this proposal? Might it be helpful to have a similar process as ghc-proposals for changes in base and the boot libraries that do not otherwise affect the compiler or the language, so as to track the status of these things more consistently?

i am strongly +1, fwiw

current situation is very unfortunate and this would mean progress

Cheers Ben

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

2017-02-27 13:19 GMT+01:00 Kosyrev Serge :

Good day!

If there is an interest in prior art, /and/ there is a motivation in making things future-proof, there is that somewhat elaborate construction coming from Common Lisp:

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node203.html [...]

And something more (= a quarter century ;-) recent from C++-land: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0011r0.html Cheers, S.