On Wed, Jan 26, 2005 at 01:39:01PM -0000, Simon Marlow wrote: > On 25 January 2005 19:45, Duncan Coutts wrote: > > > On Tue, 2005-01-25 at 19:12 +0000, Ben Rudiak-Gould wrote: > >> My concern here is that someone will actually use the library once it > >> ships, with the following consequences: > >> > >> 1. Programs using the library will have predictable > >> (exploitable) bugs in pathname handling. > >> > >> 2. It will never be possible to change the current weird > >> behavior, because it might break legacy code. The System.FilePath > >> library will > >> have to remain in GHC forever in its current form, enticing > >> programmers with its promise of easy pathname handling and then > >> cruelly breaking its contract. > >> > >> If no one uses it in production code then we can fix it at our > >> leisure, and having it out there with "experimental" status isn't > >> necessarily a bad thing in that case. It just feels like we're > >> playing a dangerous game. > > > > That's a sufficiently persuasive argument for me! > > > > Could we just punt this library for this release. After all we can add > > libraries in a later point release (eg 6.4.1) you just can't change > > existing APIs. > > We can't add libraries in a point release, because there's no way for > code to use conditional compilation to test the patchlevel version > number. > > This seems to be a common misconception, probably brought about by the > fact that the time between major releases of GHC is getting quite long. > Perhaps I should stop writing email and get some work done :)
too bad we can't do things like #if exists(module System.Path) import System.Path #else ... #endif I still find it perplexing that there isn't a decent standard haskell preprocessor.... John -- John Meacham - ârepetae.netâjohnâ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe