Hello Haskellers, There was a long discussion in October 2004, about the a FilePath module which is currently used in Cabal. There was an idea to move it to the standard libraries but since there were a lot of objections it was removed. http://www.haskell.org/pipermail/libraries/2004-October/002591.html I would like to hear what the community think we need for the proper file path handling. This module is important if we would like to make Haskell more portable. Please answer to the following questions: * Have you used the existing FilePath module and what do you think about it? Do you found it useful? Have you made any significant bugfixes or extensions to it? * Will you be happy with a library that represents the file path as String? The opposite is to use ADT for it. The disadvantage is that with the current IO library we should convert from ADT to String and back again each time when we have to do any IO. The ADT may have advantages for the internal library implementation. * Do you think that we have to use unboxed arrays of Word8/Word16 for file path? Any other suggestions are welcome. Since such kind of discussions are going to be rather long please reply to libraries@haskell.org Cheers, Krasimir
Hi,
* Have you used the existing FilePath module and what do you think about it? Do you found it useful? Have you made any significant bugfixes or extensions to it?
I wrote a separate FilePath module for Yhc, which is available at: http://www.cs.york.ac.uk/fp/darcs/yhc-devel/src/compiler98/Util/FilePath.hs The advantage of this one is that it doesn't use any #ifdef's, so is entirely portable between Unix/Windows - important if you want to be able to create a binary that runs anywhere. Thanks Neil
On Fri, Feb 03, 2006 at 11:29:34AM +0000, Neil Mitchell wrote:
I wrote a separate FilePath module for Yhc, which is available at: http://www.cs.york.ac.uk/fp/darcs/yhc-devel/src/compiler98/Util/FilePath.hs
The advantage of this one is that it doesn't use any #ifdef's, so is entirely portable between Unix/Windows - important if you want to be able to create a binary that runs anywhere.
also if you want to manipulate windows paths from unix and vice versa. any standard library should support that sort of thing. John -- John Meacham - ⑆repetae.net⑆john⑈
[move to libraries@haskell.org] Yes. I agree here. There should be two modules say: System.FilePath.Posix & System.FilePath.Windows. There should be a third module System.FilePath that have to use the native path. It should switch between the Posix and Windows implementations either at runtime (Hugs, NHC) or compile time (GHC). Cheers, Krasimir 2006/2/3, John Meacham <john@repetae.net>:
On Fri, Feb 03, 2006 at 11:29:34AM +0000, Neil Mitchell wrote:
I wrote a separate FilePath module for Yhc, which is available at: http://www.cs.york.ac.uk/fp/darcs/yhc-devel/src/compiler98/Util/FilePath.hs
The advantage of this one is that it doesn't use any #ifdef's, so is entirely portable between Unix/Windows - important if you want to be able to create a binary that runs anywhere.
also if you want to manipulate windows paths from unix and vice versa. any standard library should support that sort of thing. John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov:
[...]
* Will you be happy with a library that represents the file path as String? The opposite is to use ADT for it. The disadvantage is that with the current IO library we should convert from ADT to String and back again each time when we have to do any IO. The ADT may have advantages for the internal library implementation.
I would very much prefer an ADT. An ADT would describe the actual logical structure of a file path and this is something we should always try to achieve.
* Do you think that we have to use unboxed arrays of Word8/Word16 for file path?
We have to be careful here. As far as I know, file paths are lists of *characters* (i.e., strings) under Windows when using some new API but they are lists of *bytes* under POSIX.
[...]
Cheers, Krasimir
Best wishes, Wolfgang
Wolfgang Jeltsch <wolfgang@jeltsch.net> writes:
Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov:
[...]
* Will you be happy with a library that represents the file path as String? The opposite is to use ADT for it. The disadvantage is that with the current IO library we should convert from ADT to String and back again each time when we have to do any IO. The ADT may have advantages for the internal library implementation.
I would very much prefer an ADT. An ADT would describe the actual logical structure of a file path and this is something we should always try to achieve.
Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions? I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library. Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear? peace, isaac
Isaac Jones wrote:
Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions?
I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library.
Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear?
The reason we can't just go right ahead and do The Right Thing (i.e. introduce a new ADT for FilePaths) is because it touches so much other stuff, including stuff that also needs revising, so it doesn't feel right to just fix the FilePath library. Experience with GHC releases has left me with the opinion that it's better to group breaking changes together rather than dribble them out - people only have to modify their code once, and conditional compilation gets fewer cases. So I'm of the opinion that introducing an ADT for FilePaths is something that should wait until the I/O library is revised. In the meantime, we should include a String-based Data.FilePath library in Haskell'. It's not as elegant, but it's terribly practical, and that's one goal of Haskell'. As a first step, can someone package up Data.FilePath as a Cabal package so that at least we can all start using the same one? Cheers, Simon
On 2/6/06, Simon Marlow <simonmarhaskell@gmail.com> wrote:
Isaac Jones wrote:
Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions?
I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library.
Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear?
The reason we can't just go right ahead and do The Right Thing (i.e. introduce a new ADT for FilePaths) is because it touches so much other stuff, including stuff that also needs revising, so it doesn't feel right to just fix the FilePath library.
Experience with GHC releases has left me with the opinion that it's better to group breaking changes together rather than dribble them out - people only have to modify their code once, and conditional compilation gets fewer cases.
So I'm of the opinion that introducing an ADT for FilePaths is something that should wait until the I/O library is revised. In the meantime, we should include a String-based Data.FilePath library in Haskell'. It's not as elegant, but it's terribly practical, and that's one goal of Haskell'.
As a first step, can someone package up Data.FilePath as a Cabal package so that at least we can all start using the same one?
Already done. Darcs repository: http://scannedinavian.com/~lemmih/FilePath/ Tarball: http://hackage.haskell.org/packages/FilePath-0.1.0.tgz -- Friendly, Lemmih
On Mon, Feb 06, 2006 at 03:36:17PM +0000, Simon Marlow wrote:
The reason we can't just go right ahead and do The Right Thing (i.e. introduce a new ADT for FilePaths) is because it touches so much other stuff, including stuff that also needs revising, so it doesn't feel right to just fix the FilePath library.
Experience with GHC releases has left me with the opinion that it's better to group breaking changes together rather than dribble them out - people only have to modify their code once, and conditional compilation gets fewer cases.
So I'm of the opinion that introducing an ADT for FilePaths is something that should wait until the I/O library is revised. In the meantime, we should include a String-based Data.FilePath library in Haskell'. It's not as elegant, but it's terribly practical, and that's one goal of Haskell'.
I don't see why merely introducing an ADT would break anyone's code, as there is no existing standard filepath model, therefore no code to break! The code I posted works with the current IO library and uses an ADT. I also think it has the potential to be compatible with a redesigned IO library. I further believe in incremental change when possible. So if it's possible to try out a "better" approach to filepaths (whatever "better" may be) without redesigning IO, IMO that's exactly what we should do. Now it may be that the need for a filepath library is so great, and "better" approaches sufficiently untested, that we should use whatever exists and works right now. But that is a separate question. Andrew
On Mon, Feb 06, 2006 at 03:36:17PM +0000, Simon Marlow wrote:
So I'm of the opinion that introducing an ADT for FilePaths is something that should wait until the I/O library is revised. In the meantime, we should include a String-based Data.FilePath library in Haskell'. It's not as elegant, but it's terribly practical, and that's one goal of Haskell'.
As a first step, can someone package up Data.FilePath as a Cabal package so that at least we can all start using the same one?
how about we take the library as is for now and then add newtype FilePath = FilePath String filePathToString (FilePath s) = s stringToFilePath s = FilePath s that way, when FilePath is replaced by something more interesting, no code dealing with it needs to change as it is already written to an ADT (though a simple one for now) and we could experiment with more advanced representations without breaking anyones code. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (8)
-
Andrew Pimlott -
Isaac Jones -
John Meacham -
Krasimir Angelov -
Lemmih -
Neil Mitchell -
Simon Marlow -
Wolfgang Jeltsch