Re: [Haskell-cafe] File path programme

2005-01-30 Thread David Roundy
On Sun, Jan 30, 2005 at 09:25:00PM +0100, Marcin 'Qrczak' Kowalczyk wrote: > David Roundy <[EMAIL PROTECTED]> writes: > > > No, it's not Unix-specific, it's portable. If you want to write > > portable C code, you have to use the standard library, which means > > that file names are represented as

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Marcin 'Qrczak' Kowalczyk
Glynn Clements <[EMAIL PROTECTED]> writes: > And it isn't a theoretical issue. E.g. in an environment where EUC-JP > is used, filenames may begin with $)B (designate JISX0208 to G1), > or they may not (because G1 is assumed to contain JISX0208 initally). I think such encodings are never used as d

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Marcin 'Qrczak' Kowalczyk
David Roundy <[EMAIL PROTECTED]> writes: > No, it's not Unix-specific, it's portable. If you want to write > portable C code, you have to use the standard library, which means > that file names are represented as Ptr CChar. I disagree. We are talking about portable Haskell, not portable C. The n

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Marcin 'Qrczak' Kowalczyk
Glynn Clements <[EMAIL PROTECTED]> writes: >> Then of course there's the issue that Win32 edge >> labels are Unicode, while Posix edge labels are [Word8]. Hmm. > > Strictly speaking, they're [CChar], but I doubt that anyone will ever > implement Haskell on a platform where a byte isn't 8 bits wid

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Glynn Clements
Ben Rudiak-Gould wrote: > Is there an MSDN page that actually gives a grammar, or at least a > taxonomy, of Win32 pathnames? That would be useful. It would also be longer than "War and Peace", once you start allowing for MS-DOS "8.3" pathnames, codepages, the fact that anything anywhere which c

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Glynn Clements
robert dockins wrote: > > I don't pretend to fully understand various unicode standard but it > > seems to me that these problems are deeper than file path library. The > > equation (decode . encode) > > /= id seems confusing for me. Can you give me an example when this > > happen? > > I am pre

Re: [Haskell-cafe] File path programme

2005-01-30 Thread David Roundy
On Sun, Jan 30, 2005 at 02:17:01PM +, Glynn Clements wrote: > Ben Rudiak-Gould wrote: > > > pathToForeign :: p -> IO (Ptr CChar) > > > pathFromForeign :: Ptr CChar -> IO p > > > > This interface is problematic. Is the pointer returned by pathToForeign > > a heap pointer which the caller is

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Glynn Clements
Keean Schupke wrote: > >I guess it's just that I'm more concerned with making possible what is > >currently impossible (according to the library standards)--that is, using > >FFI and IO on the same file--rather than just adding utility features that > >application developers could have written th

Re: [Haskell-cafe] File path programme

2005-01-30 Thread Glynn Clements
Ben Rudiak-Gould wrote: > Symbolic links complicate things a bit, since they are followed like > edges but are actually paths. Actually, they're essentially arbitrary byte strings. The OS doesn't automatically require them to be valid paths. Most of the API functions to which you might pass a

Re: [Haskell-cafe] File path programme

2005-01-28 Thread robert dockins
I don't pretend to fully understand various unicode standard but it seems to me that these problems are deeper than file path library. The equation (decode . encode) /= id seems confusing for me. Can you give me an example when this happen? I am pretty sure that ISO 2022 encoded strings can have m

Re: [Haskell-cafe] File path programme

2005-01-28 Thread Krasimir Angelov
On Thu, 27 Jan 2005 16:31:21 -0500, robert dockins <[EMAIL PROTECTED]> wrote: > > I don't pretend to fully understand various unicode standard but it > > seems to me that these problems are deeper than file path library. The > > equation (decode . encode) > > /= id seems confusing for me. Can you g

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Krasimir Angelov
I don't pretend to fully understand various unicode standard but it seems to me that these problems are deeper than file path library. The equation (decode . encode) /= id seems confusing for me. Can you give me an example when this happen? What can we do when the file name is passed as command lin

Re: [Haskell-cafe] File path programme

2005-01-27 Thread robert dockins
Even simple manipulations break in the presence of encoding issues, or even just of unusual paths. What is the extension of "\\.\TAPE0" ? Its not "\TAPE0". BTW this is a valid path on Windows 2000 upwards. If you don't care about corner cases, then you have no worries. It would be nice to

Re: [Haskell-cafe] File path programme

2005-01-27 Thread robert dockins
- Keep the existing System.IO API the same. openFile, createDirectory ... will take the file path as string. The problem is that "string" means different things in haskell and in C. A C "string" is really just a contiguous sequence of octets in memory. A haskell string has a particular interpreta

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Marcin 'Qrczak' Kowalczyk
John Meacham <[EMAIL PROTECTED]> writes: > 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 For my language Kogut I designed a syntax if

Re: [Haskell-cafe] File path programme

2005-01-27 Thread robert dockins
While true, I don't see what this has to do with the choice between PathStart and Maybe PathRoot. The types are isomorphic; we can detect and simplify the /.. case either way. True Because of the above problem, I'm willing to treat path fragments (Relative in both lattices) as a special case. Bu

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Marcin 'Qrczak' Kowalczyk
Gregory Wright <[EMAIL PROTECTED]> writes: > Actually, Common Lisp specifies a special data type to handle > logical filepaths, which are distinct from file path strings. Having > had to debug common lisp code that uses this (written by other > people) I've observed that this attempt to do the "Ri

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Marcin 'Qrczak' Kowalczyk
Robert Dockins <[EMAIL PROTECTED]> writes: > More than you would think, if you follow the conventions of modern > unix shells. eg, "foo/.." is always equal to ".", For the OS it's not the same if foo is a non-local symlink. Shells tend to resolve symlinks themselves on cd, and "cd .." means to r

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Gregory Wright
Hello, On Jan 27, 2005, at 10:46 AM, Krasimir Angelov wrote: Hello Guys, Let me propose another solution which is simpler (at least from my point of view)and will not break the existing. When I designed the API of the original System.FilePath library I looked at OS.Path modules from Python and ML.

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Krasimir Angelov
Hello Guys, Let me propose another solution which is simpler (at least from my point of view)and will not break the existing. When I designed the API of the original System.FilePath library I looked at OS.Path modules from Python and ML. They both uses plain string to keep the file path but does p

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Ben Rudiak-Gould
Robert Dockins wrote: >This is true in a sense, but I think making the distinction explicit is >helpful for a number of the operations we want to do. For example, what >is the parent of the relative path "."? Answer is "..". What is the >parent of "/." on unix? Answer is "/.". While true, I don

Re: [Haskell-cafe] File path programme

2005-01-27 Thread robert dockins
Warning: I'm not interested in a path parsing/combining library, so my criticisms are perhaps unrelated to your goals. One thing that I'd be interested in seeing for any Path class would be a simple instance for FilePath (or String, if you want to imagine FilePath will be changed). Not everyone w

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Keean Schupke
Jules Bean wrote: only it isn't. That's a property of a shell, the underlying OS allows spaces in file names with no need for an escaping mechanism. Okay, that was a mistake... but it does not change the point, that pathToString needs to work out what platform it is on, and doing it without typec

Re: [Haskell-cafe] File path programme

2005-01-27 Thread David Roundy
On Thu, Jan 27, 2005 at 11:33:21AM +, Keean Schupke wrote: > > >I guess it's just that I'm more concerned with making possible what is > >currently impossible (according to the library standards)--that is, using > >FFI and IO on the same file--rather than just adding utility features that > >a

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Jules Bean
On 27 Jan 2005, at 11:33, Keean Schupke wrote: Except paths are different on different platforms... for example: /a/b/../c/hello\ there/test and: A:\a\b\ notice how the backslash is used to 'escape' a space or meta-character on only it isn't. That's a property of a shell, the underlying OS allows

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Keean Schupke
I guess it's just that I'm more concerned with making possible what is currently impossible (according to the library standards)--that is, using FFI and IO on the same file--rather than just adding utility features that application developers could have written themselves. I suppose we don't need

Re: [Haskell-cafe] File path programme

2005-01-27 Thread David Roundy
On Wed, Jan 26, 2005 at 10:20:12PM -0500, Robert Dockins wrote: > class (Show p) => Path p where > isAbsolute :: p -> Bool > isRelative :: p -> Bool > isRelative = not . isAbsolute > basename :: p -> String > parent :: p -> p > pathAppend :: p -> p -> p > pathExtend :: p -> String ->

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Keean Schupke
Ben Rudiak-Gould wrote: I'm tentatively opposed to (B), since I think that the only interesting difference between Win32 and Posix paths is in the set of starting points you can name. (The path separator isn't very interesting.) But maybe it does make sense to have separate starting-point ADTs

Re: [Haskell-cafe] File path programme

2005-01-27 Thread Keean Schupke
Georg Martius wrote: Hi, I think Isaac's idea is pretty nice, to have an easy way to add documentation in a collaborative manner. I have the following in mind: A separate wiki which supports generating haddock documentation. Ideally one would see the haddock documentation as it is and would clic

Re: [Haskell-cafe] File path programme

2005-01-26 Thread Robert Dockins
Here is my first cut at this. The unix implementation mostly works, the windows one just has some datatypes sketched out, but it typechecks. -- module FilePath where import Data.Word (Word8) import Text.ParserCombinators.Parsec import Text.ParserCombinators.Parsec.Error import System (getArgs)

Re: [Haskell-cafe] File path programme

2005-01-26 Thread Robert Dockins
> I would say that all paths are relative to something, whether it's the > Unix root, or the current directory, or whatever. Therefore I would call > this something like PathStart, and add: > > | CurrentDirectory > | CurrentDirectoryOfWindowsDrive Char > | RootOfCurrentWindowsDrive

Re: [Haskell-cafe] File path programme

2005-01-26 Thread John Meacham
On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote: > On 25 January 2005 19:45, Duncan Coutts wrote: > > > On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote: > >> My concern here is that someone will actually use the library once it > >> ships, with the following consequences: >

Re: [Haskell-cafe] File path programme

2005-01-26 Thread Ben Rudiak-Gould
robert dockins wrote: > After the discussion about file paths over the last several days I went home and put together a quick trial implementation for unix file paths, with the idea of adding windows, SMB and maybe VMS (why not?) paths. This is great. Comments below. > data PathRoot >= UnixF

Re: [Haskell-cafe] File path programme

2005-01-26 Thread Georg Martius
Hi, I think Isaac's idea is pretty nice, to have an easy way to add documentation in a collaborative manner. I have the following in mind: A separate wiki which supports generating haddock documentation. Ideally one would see the haddock documentation as it is and would click to a function or typ

Re: [Haskell-cafe] File path programme

2005-01-26 Thread robert dockins
After the discussion about file paths over the last several days I went home and put together a quick trial implementation for unix file paths, with the idea of adding windows, SMB and maybe VMS (why not?) paths. It is based on a Path class. I'll post it later when I get home. However, I wil

Re: [Haskell-cafe] File path programme

2005-01-26 Thread David Roundy
On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote: > 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. On the other hand, darcs doesn't rely on version numbers when looking for libraries (

Re: [Haskell-cafe] File path programme

2005-01-26 Thread David Roundy
On Wed, Jan 26, 2005 at 01:34:39PM -, Simon Marlow wrote: > ... We can therefore: > > (a) make System.IO.FilePath be the new type, which is different from, > and incompatible with, IO.FilePath. Similarly for > System.IO.openFile, System.Directory.removeFile, and so on. > > (b) o

RE: [Haskell-cafe] File path programme

2005-01-26 Thread Simon Marlow
On 25 January 2005 19:45, Duncan Coutts wrote: > On Tue, 2005-01-25 at 19:12 +, 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 >> (exploit

RE: [Haskell-cafe] File path programme

2005-01-26 Thread Simon Marlow
[ moving to [EMAIL PROTECTED] ] On 26 January 2005 12:22, Malcolm Wallace wrote: >> 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. > > FWIW, I agree with Duncan, Ben, and Peter, that

Re: [Haskell-cafe] File path programme

2005-01-26 Thread Malcolm Wallace
> 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. FWIW, I agree with Duncan, Ben, and Peter, that the new System.FilePath interface is broken, and the implementation more so. It would be

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Isaac Jones
Mark Carroll <[EMAIL PROTECTED]> writes: > On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote: > (snip) >> If problems are in the implementation but the interface is right, then >> the module should be provided. It can be fixed later. > (snip) > > A lot of the Haskell libraries are sufficiently

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Mark Carroll
On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote: (snip) > If problems are in the implementation but the interface is right, then > the module should be provided. It can be fixed later. (snip) A lot of the Haskell libraries are sufficiently poorly documented that I work out what they do by exp

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Duncan Coutts
On Tue, 2005-01-25 at 19:12 +, 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

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Ben Rudiak-Gould
Jules Bean wrote: > [...] it is an extension of the notion that "/foo/" and "/foo" > refer to the same directory. (Except, apparently, in the presence > of symbolic links... or so I have some vague memory) Yes, "/foo/" is equivalent to "/foo/.", which is not always the same as "/foo". If "/foo" is

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Marcin 'Qrczak' Kowalczyk
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes: > >Doing a reasonable job on System.FilePath, even if it isn't > >perfect, will help prevent lots of applications from falling into > >common traps, and help make more code portable. > > But the library code itself falls into the same traps! It's a g

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Ben Rudiak-Gould
Simon Marlow wrote: >Doing a reasonable job on System.FilePath, even if it isn't perfect, >will help prevent lots of applications from falling into common traps, >and help make more code portable. But the library code itself falls into the same traps! It's a great example of the kind of code we sh

RE: [Haskell-cafe] File path programme

2005-01-25 Thread Simon Marlow
On 24 January 2005 22:11, Ben Rudiak-Gould wrote: > Please, let's not ship this with the hierarchical libraries. It's not > ready for prime time. We decided to provide this library for purely pragmatic reasons. It's better than nothing. http://www.haskell.org/pipermail/libraries/2004-October/

Re: [Haskell-cafe] File path programme

2005-01-25 Thread David Roundy
On Tue, Jan 25, 2005 at 01:32:29PM +0200, Krasimir Angelov wrote: > > splitFileName "/foo/bar" ==> ("/foo","bar") > > splitFileName "/foo//bar" ==> ("/foo/","bar") > >(definitely a bug) > > Is "/foo//bar" valid file path and what does "//" mean? "//" means the same thing as "/". In unix yo

Re: [Haskell-cafe] File path programme

2005-01-25 Thread Jules Bean
On 25 Jan 2005, at 11:32, Krasimir Angelov wrote: splitFileName "/foo/bar" ==> ("/foo","bar") splitFileName "/foo//bar" ==> ("/foo/","bar") (definitely a bug) Is "/foo//bar" valid file path and what does "//" mean? pathParents "/foo///bar" ==> ["/","/foo","/foo","/foo","/foo/bar"] Again what

[Haskell-cafe] File path programme

2005-01-25 Thread Krasimir Angelov
Hello, Guys The System.FilePath might not be perfect and might not handle some unusual cases very well. Most of functions in this module are collected from Cabal/Alex/Happy/Haddock. Some of these tools already use their own functions for file path handling. Special care was taken to make them more

Re: [Haskell-cafe] File path programme

2005-01-24 Thread Ben Rudiak-Gould
Isaac Jones wrote: >You might be interested in the new FilePath module that's in the >works. There's been a lot of work to make these functions portable. > >http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs I didn't realize this was in CVS. IMHO this library is de

Re: [Haskell-cafe] File path programme

2005-01-24 Thread Graham Klyne
At 15:17 20/01/05 -0500, Mark Carroll wrote: I tried writing a little command-line utility to find the relative path of one thing from another thing (with Unix-like systems in mind). ... FWIW, there's logic to do something like this in my URI module [1]. Bear in mind that there is not, in general

Re: [Haskell-cafe] File path programme

2005-01-23 Thread Marcin 'Qrczak' Kowalczyk
Isaac Jones <[EMAIL PROTECTED]> writes: > You might be interested in the new FilePath module that's in the > works. There's been a lot of work to make these functions portable. > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs splitFileExt "foo" = ("foo", ""

Re: [Haskell-cafe] File path programme

2005-01-22 Thread Isaac Jones
You might be interested in the new FilePath module that's in the works. There's been a lot of work to make these functions portable. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs peace, isaac ___ Haskell-Cafe m

[Haskell-cafe] File path programme

2005-01-20 Thread Mark Carroll
I tried writing a little command-line utility to find the relative path of one thing from another thing (with Unix-like systems in mind). For example, $ ./pathfromof /etc/init.d/ /etc/X11/XF86Config-4 ../X11/XF86Config-4 $ ./pathfromof /tmp/baz/ /tmp/foo/ . $ ls -l /tmp/baz lrwxr-xr-x 1 markc mar