| > That would take care of the incompatibility here, but | > it's a slippery slope. Should Haskell provide you with | > a platform-independent view of filenames and file systems?
Just because that wouldn't be practical doesn't mean it wouldn't be the right thing to do (and vice versa, unfortunately). As I mentioned to Sigbjorn earlier, I'd like to see Haskell, as a higher-level language, being better at protecting programmers from details they don't want to see, even if other languages don't do this. Ghc's graceful handling of \ and / in paths is a nice example. I assumed from Sigbjorn's response that the system call implementing doesDirectoryExist is not the only one suffering from this or other unwanted "features", so he wasn't against fixing this but pointed out that just fixing this one wouldn't be a clean overall solution. For starters, it would be nice to have a list of such portability issues, so that it'd be easier to avoid them (or at least to spot them later), and posted at haskell.org, so that Haskellers refer to it when writing code. When I was still a C programmer, seeing such a list of things to avoid in portable software was quite helpful, and now I'm more and more running into non-portable tricks in Haskell programs.. To ensure portability not only across ghc on different OSs, but also across different Haskell implementations on different OSs, any compatibility fixes should probably be shared between Haskell implementations as well, so perhaps this is an issues for the libraries? | For example, I think that Haskell 98 library functions should have | particular care applied to them and I think that the trailing "/" | problem should be eliminated. Allowable cross platform variations | should be documented in the standard. Agreed. >This is exactly my position too. Yes, it's a slippery slope, but so is >all of life. We should strive to conceal gratuitous differences where >they are easy to conceal, but without ever pretending that the Win32 and >Unix are identical. Okay. I assume that the reason mingw itself doesn't provide even such "shallow" compatibility wrappers is that they don't want to introduce extra libraries? Otherwise one could try to lobby them.. As for the specific problem at hand, it seems that a trailing slash in doesDirectoryExist is always an error, no? So, Haskell implementations should either deal with it gracefully (as currently on unixes, or by removing trailing slashes on windows) or report the error (if no entry, check for trailing slash), not fail silently (as currently on windows).. In my case, I don't have control about the path parameters to doesDirectoryExist, so I redirect calls via a trivial wrapper that removes trailing slashes. But there's no reason why this code should be in this application. Cheers, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/ _______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
