Re: Directory.doesDirectoryExist inconsistency
| 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
Re: Directory.doesDirectoryExist inconsistency
Hi all. | across those platforms up to the limits of available programmer time and | common sense. Would anyone care to remove the trailing '/' or '\' in the Win32 version of doesDirectoryExist? I'll put it on my list, but it's so much easier to write emails about the problem than to write code. Is there a deadline for 6.04.2 I need to meet? Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Directory.doesDirectoryExist inconsistency
| 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? | | I think that if a language implementation takes the trouble to provide a | cross-platform library function then that function should be consistent | across those platforms up to the limits of available programmer time and | common sense. | | 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. | By the same logic, I don't believe that much effort at all should be applied | to reproducing cross-platform behaviour in the GHC Posix library on systems | which do not support Posix. 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. Would anyone care to remove the trailing '/' or '\' in the Win32 version of doesDirectoryExist? Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Directory.doesDirectoryExist inconsistency
Sigbjorn (and others interested in Win32 I/O behaviour) The fact that MS CRT differs from Unix doesn't mean that the Haskell interface should necessarily differ. The Haskell impl of doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in order to make the behaviour consistent. Where it's possible to get consistent behaviour, we should strive for that. Do you agree? Simon | -Original Message- | From: Sigbjorn Finne [mailto:sof;galois.com] | Sent: 16 October 2002 15:54 | To: Claus Reinke | Cc: [EMAIL PROTECTED] | Subject: Re: Directory.doesDirectoryExist inconsistency | | This is known behaviour of the MS CRT implementation | of stat() on directories -- trailing slashes will cause it to | report ENOENT. | | Undesirable behaviour, you might (reasonably) say, but | the format of FilePaths is left system-specific by Haskell98. | | --sigbjorn | | - Original Message - | From: Claus Reinke [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, October 16, 2002 07:21 | Subject: Directory.doesDirectoryExist inconsistency | | | I've just been chasing a portability problem, where a largish third-party | program works fine on our suns (ghc-5.02.3), but chokes under | cygwin/windows (ghc-5.04). Comes down to an inconsistency in the | handling of (trailing?) slashes in Directory.doesDirectoryExist (see | a and b below). | | ... | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Directory.doesDirectoryExist inconsistency
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? --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED]; Claus Reinke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 08:50 Subject: RE: Directory.doesDirectoryExist inconsistency Sigbjorn (and others interested in Win32 I/O behaviour) The fact that MS CRT differs from Unix doesn't mean that the Haskell interface should necessarily differ. The Haskell impl of doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in order to make the behaviour consistent. Where it's possible to get consistent behaviour, we should strive for that. Do you agree? Simon | -Original Message- | From: Sigbjorn Finne [mailto:sof;galois.com] | Sent: 16 October 2002 15:54 | To: Claus Reinke | Cc: [EMAIL PROTECTED] | Subject: Re: Directory.doesDirectoryExist inconsistency | | This is known behaviour of the MS CRT implementation | of stat() on directories -- trailing slashes will cause it to | report ENOENT. | | Undesirable behaviour, you might (reasonably) say, but | the format of FilePaths is left system-specific by Haskell98. | | --sigbjorn | | - Original Message - | From: Claus Reinke [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, October 16, 2002 07:21 | Subject: Directory.doesDirectoryExist inconsistency | | | I've just been chasing a portability problem, where a largish third-party | program works fine on our suns (ghc-5.02.3), but chokes under | cygwin/windows (ghc-5.04). Comes down to an inconsistency in the | handling of (trailing?) slashes in Directory.doesDirectoryExist (see | a and b below). | | ... | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Directory.doesDirectoryExist inconsistency
Hi there. That would take care of the incompatibility here, but it's a slippery slope. Just how slippery the filename slope can get is shown by Common Lisp filename/logical pathnames: http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1063.html#SEC1063 Should Haskell provide you with a platform-independent view of filenames and file systems? I think that if a language implementation takes the trouble to provide a cross-platform library function then that function should be consistent across those platforms up to the limits of available programmer time and common sense. 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. By the same logic, I don't believe that much effort at all should be applied to reproducing cross-platform behaviour in the GHC Posix library on systems which do not support Posix. Generally I think that compilers striving to support production programming should, where possible, provide at least basic coverage of low level system specific libraries and low level programming. Such coverage in tandem with efficient higher level abstracted libraries such as ObjectIO, gives programmers lots of useful options and is a great strength of GHC. Cheers Mike Thomas. --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED]; Claus Reinke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 08:50 Subject: RE: Directory.doesDirectoryExist inconsistency Sigbjorn (and others interested in Win32 I/O behaviour) The fact that MS CRT differs from Unix doesn't mean that the Haskell interface should necessarily differ. The Haskell impl of doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in order to make the behaviour consistent. Where it's possible to get consistent behaviour, we should strive for that. Do you agree? Simon | -Original Message- | From: Sigbjorn Finne [mailto:sof;galois.com] | Sent: 16 October 2002 15:54 | To: Claus Reinke | Cc: [EMAIL PROTECTED] | Subject: Re: Directory.doesDirectoryExist inconsistency | | This is known behaviour of the MS CRT implementation | of stat() on directories -- trailing slashes will cause it to | report ENOENT. | | Undesirable behaviour, you might (reasonably) say, but | the format of FilePaths is left system-specific by Haskell98. | | --sigbjorn | | - Original Message - | From: Claus Reinke [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, October 16, 2002 07:21 | Subject: Directory.doesDirectoryExist inconsistency | | | I've just been chasing a portability problem, where a largish third-party | program works fine on our suns (ghc-5.02.3), but chokes under | cygwin/windows (ghc-5.04). Comes down to an inconsistency in the | handling of (trailing?) slashes in Directory.doesDirectoryExist (see | a and b below). | | ... | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Directory.doesDirectoryExist inconsistency
I've just been chasing a portability problem, where a largish third-party program works fine on our suns (ghc-5.02.3), but chokes under cygwin/windows (ghc-5.04). Comes down to an inconsistency in the handling of (trailing?) slashes in Directory.doesDirectoryExist (see a and b below). Consequence: under cygwin, the program doesn't see the existing directory, tries to create it, and fails (error message doesn't seem to include the file name, btw). Cheers, Claus $ uname -a CYGWIN_98-4.10 VAIO 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude Prelude Directory.doesDirectoryExist u = print False Prelude Directory.createDirectory u Prelude Directory.doesDirectoryExist u = print True Prelude Directory.doesDirectoryExist u/ = print -- (a) note this one, compare with b False Prelude Directory.doesDirectoryExist u\\ = print False Prelude :q Leaving GHCi. uname -a SunOS myrtle 5.8 Generic_108528-16 sun4u sparc SUNW,Ultra-4 ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Prelude Directory.doesDirectoryExist u = print False Prelude Directory.createDirectory u Prelude Directory.doesDirectoryExist u = print True Prelude Directory.doesDirectoryExist u/ = print-- (b) note this one, compare with a True Prelude Directory.doesDirectoryExist u\\ = print False Prelude :q Leaving GHCi. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
