Hi, I have written a System.FilePath module in part based on the one in Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim is to try and get this module into the base package, as FilePath's are something many programs use, but its all too easy to hack up a little function that gets it right most of the time on most platforms, and there lies a source of bugs. This module is Posix (Linux) and Windows capable - just import System.FilePath and it will pick the right one. Of course, if you demand Windows paths on all OS's, then System.FilePath.Windows will give you that (same with Posix). Written in Haskell 98 + Heirarchical Modules. Haddock: http://www-users.cs.york.ac.uk/~ndm/projects/filepath/System-FilePath.html Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/filepath Source: http://www.cs.york.ac.uk/fp/darcs/filepath/System/FilePath.hs Homepage: http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php Tests: http://www.cs.york.ac.uk/fp/darcs/filepath/Tests.hs If you go to the haddock page there are a few little examples at the top of the file. If anyone could make any comments on the interface, the semantics of the operations (look at the Tests file if you don't want to go prodding the code), missing features etc. that would be very handy. The interface is not yet stable as a warning to those who choose to use it (although I hope its close - that depends on your comments!) Thanks Neil PS. Thanks to Marc Webber for code contributions, shapr for suggestions and a few others.
Hello Neil, Thursday, June 29, 2006, 8:42:08 PM, you wrote:
I have written a System.FilePath module in part based on the one in Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim is to try and get this module into the base package, as FilePath's are
i think that filepath manipulation is among the things that absolutely need to be included in base libs (together with jregex and string manipulation). but just to let you know: 1) there are two independent filepath modules used with little modifications in all projects i seen. They both included in MissingH (FilePath.hs and NameManip.hs). Andrew Pimlott published it's own module in libraries list (look at February "System.FilePath survey" topic). May be, you can borrow some new functionality from these sources 2) As you can see in this February discussion, one of debatable question was support of ADTs for filanames. We can talk about this now. Currently there is ByteStrings with forecoming UTF-8 support and it's possible to implement FilePath module so it will work both with filenames represented by String and ByteString. It's also possible to add support of such filenames to IO library (at least, my own) (even without all these changes, i will be glad to see this module in base package, as long as it's interface leave space for future innovations) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi
1) there are two independent filepath modules used with little modifications in all projects i seen. They both included in MissingH (FilePath.hs and NameManip.hs). From what I can tell, FilePath.hs is the one from Cabal, which I already used as a reference. As far as I can tell, this library is also a superset of NameManip.hs.
2) As you can see in this February discussion, one of debatable question was support of ADTs for filanames. We can talk about this now. Currently there is ByteStrings with forecoming UTF-8 support and it's possible to implement FilePath module so it will work both with filenames represented by String and ByteString. It's also possible to add support of such filenames to IO library (at least, my own) I jumped with "no" - since it breaks things like readFile/writeFile. I would rather something more practical and less pure/safe thats immediately useable with less cost. Of course, I hope the interface does not make any demands on the representation - and that other FilePath's could be used in place, in a similar way to ByteString and ByteString.Lazy coexisting with the same interface but different representations.
The other important point regarding ADT's is what is a FilePath and what is a String? If I set the extension of a FilePath, is that extension itself a FilePath or a String? What if I set the drive or the filename? Is a filename on its own a FilePath? Even though it doesn't correspond to a file, because its lost its context/directory and therefore cannot be used? Thanks Neil
Neil Mitchell wrote:
The other important point regarding ADT's is what is a FilePath and what is a String? If I set the extension of a FilePath, is that extension itself a FilePath or a String? What if I set the drive or the filename? Is a filename on its own a FilePath? Even though it doesn't correspond to a file, because its lost its context/directory and therefore cannot be used?
I wonder if it would be better to have an ADT for strings rather than FilePaths (to solve the issues above and also for general use in other Haskell libs). Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com
On Thu, Jun 29, 2006 at 11:14:46PM +0100, Brian Hulley wrote:
Neil Mitchell wrote:
The other important point regarding ADT's is what is a FilePath and what is a String? If I set the extension of a FilePath, is that extension itself a FilePath or a String? What if I set the drive or the filename? Is a filename on its own a FilePath? Even though it doesn't correspond to a file, because its lost its context/directory and therefore cannot be used?
I wonder if it would be better to have an ADT for strings rather than FilePaths (to solve the issues above and also for general use in other Haskell libs).
An ADT for strings wouldn't address the issue that on posixy systems, a filepath isn't a unicode string, while an ADT for FilePaths could solve that problem. And that's a significant problem, since otherwise the standard libraries would prevent certain utilities from being written in Haskell (e.g. one that computes the number of files in a directory). My leaning (and you could search the archives for a post on the subject by Ian Lynagh) is to have a class rather than an ADT for filepaths. It makes the type signature of all file IO functions more complicated, but means that you could use "real" strings, Data.ByteStrings, etc as filepaths. -- David Roundy
Hello David, Saturday, July 1, 2006, 5:17:07 PM, you wrote:
The other important point regarding ADT's is what is a FilePath and what is a String? If I set the extension of a FilePath, is that
My leaning (and you could search the archives for a post on the subject by Ian Lynagh) is to have a class rather than an ADT for filepaths.
:) i mean "Abstract Data Type" (i.e., class) when say "ADT". Just today i've realized that in Haskell ADT should has another meaning :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Sat, Jul 01, 2006 at 06:14:07PM +0400, Bulat Ziganshin wrote:
Hello David,
Saturday, July 1, 2006, 5:17:07 PM, you wrote:
The other important point regarding ADT's is what is a FilePath and what is a String? If I set the extension of a FilePath, is that
My leaning (and you could search the archives for a post on the subject by Ian Lynagh) is to have a class rather than an ADT for filepaths.
:) i mean "Abstract Data Type" (i.e., class) when say "ADT". Just today i've realized that in Haskell ADT should has another meaning :)
Oh good, then we're in agreement! :) -- David Roundy
participants (4)
-
Brian Hulley -
Bulat Ziganshin -
David Roundy -
Neil Mitchell