Re: Filename literals
Hinrik Örn Sigurðsson wrote: I was wondering if there had been any discussion about how to type file and directory names in Perl 6. I've read a couple of posts about file test operators, where some have suggested making filenames special, either as a subtype of Str or something else entirely. That way Str wouldn't have all these file test methods, which is good because not all strings are valid filenames. Considering that in the general case a file name can be any string at all, if it is going to have its own type at all, it should be disjoint from Str in the same manner that, say, Instant and Duration are disjoint from Num/Rat. When I say "disjoint", I mean conceptually that "FileName" say has an attribute of type Str rather than being defined as a subtype of Str. -- Darren Duncan
Re: Filename literals
More ideas: On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote: # bin/perl on Unix my $rel = qf/usr bin perl/; # /usr/bin/perl my $abs = qf[/usr bin perl]; ...and on Windows, would the above result in "C:\/usr\bin\perl" ? :) # The following both result in the same object (kinda): # /usr/bin/perl on Unix, C:\usr\bin\perl on Windows my $abs = qf:unix[/usr/bin/perl]; my $abs = qf:win[C:\usr\bin\perl]; Just thinking out loud. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On 2009-Aug-13, at 10:25 am, Hinrik Örn Sigurðsson wrote: I've read a couple of posts about file test operators, where some have suggested making filenames special, either as a subtype of Str or something else entirely. That way Str wouldn't have all these file test methods, which is good because not all strings are valid filenames. We should start thinking about the fundamental objects for doing IO as IO-objects. They *have* names, but they aren't names, or strings, or even filehandles (although they might *have* filehandles encapsulated inside to do the actual work). A filename is merely a way to get at the actual object, just as the string "2009/1/1" can be used to get a Date object. A string, or a handle, or an inode, or some unique filesystem spec number, or anything else you can get your hands on should be fed to a constructor: my $file = IO("/foo/bar/qux.txt"); Of course, this being P6, we can have some kind of "io" macro that parses the single item after it: my $file1 = io file://some/dir/some%20file; # the quick way my $file2 = IO.new(:protocol :uri); # the verbose way The "file:" protocol might be assumed by default, but we could even make the protocol keywords into IO-constructor macros: my $x = file:///some/local/path;# an IO object my $y = http://perl.org/index; # another one (It might even be possible to get away without the protocol, if you're willing to start all your regexes with an m and steal prefix / for the io-builder:) use io :default; $x = /home/me/stuff.txt; # the lazy way =P Then filetests and everything can belong to the IO class where they belong, as well as eliminating the need for doublets like "eval" and "evalfile". There's a lot of scope for a nice, friendly, high-level IO view; perhaps we need an IO-working group to assemble knowledge about what is and isn't possible with different filesystems and design an interface around it all. -David
Re: Filename literals
I like this way. Would it be possible to remove the special purpose of \ from strings within IO constructs? This would mean '\' could be used in naming paths as an alternative to '/', thus allowing windows and unix strings to be equivalent, eg. IO(:path<<{$root-path}/data/new>>) would be equivalent to IO(:path<<{$root-path}\data\new>>) The usefulness would be most evident for sub-directories as windows and unix have different ways of describing root, viz. 'C:\' versus '/' David Green wrote: We should start thinking about the fundamental objects for doing IO as IO-objects. They *have* names, but they aren't names, or strings, or even filehandles (although they might *have* filehandles encapsulated inside to do the actual work). A filename is merely a way to get at the actual object, just as the string "2009/1/1" can be used to get a Date object. A string, or a handle, or an inode, or some unique filesystem spec number, or anything else you can get your hands on should be fed to a constructor: Of course, this being P6, we can have some kind of "io" macro that parses the single item after it: my $file1 = io file://some/dir/some%20file; # the quick way my $file2 = IO.new(:protocol :uri); # the verbose way
Re: Filename literals
On Fri, Aug 14, 2009 at 12:34 PM, David Green wrote: > Of course, this being P6, we can have some kind of "io" macro that parses > the single item after it: > > my $file1 = io file://some/dir/some%20file; # the > quick way I don't think that's a good idea. In general, parsing an URI isn't that easy, in particular determining the end is undefined AFAIK. In your example the semicolon should probably be considered part of the URI, even though that's obviously not what you intended. Using a strings or a quoting construct may be a bit more cumbersome, but at least it isn't ambiguous. Leon
Re: Filename literals
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote: Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I ...or imagine just one, called IO::FSNode. http://perlcabal.org/syn/S32/IO.html#IO::FSNode Btw, kudos for the special quoting idea -- I love it :). And in response to David Green and his comment about working with file data vs. metadata, as a systems programmer, I've written a fair number of programs that have worried a fair bit about the metadata in the filesystem; sometimes you want to read data, and sometimes metadata. That's why the Draft IO spec specifies two separate objects. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On Fri, 14 Aug 2009, Timothy S. Nelson wrote: On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote: Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I ...or imagine just one, called IO::FSNode. Sorry, I was stupiding again. I'll ask you to imagine 4: IO::FSNode | +-IO::FileNode | +-IO::DirectoryNode | +-IO::LinkNode Role composition tree depicted above. - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On 2009-Aug-14, at 5:36 am, Richard Hainsworth wrote: Would it be possible to remove the special purpose of \ from strings within IO constructs? It's P6, anything's possible! I probably wouldn't change [what look like] ordinary quoted strings, but maybe something with a "qf//"-type construct (or would that be qf\\ ?!). My idea of using a macro was to grab almost anything that wasn't whitespace, and it doesn't have to be parsed like a normal string, so \ could be interpreted as a dir separator. Of course, / has become so standard, that it even works on Windows (kind of); on the other hand, being able to use either (or both) would be convenient for a lot of people. On 2009-Aug-14, at 7:18 am, Leon Timmermans wrote: I don't think that's a good idea. In general, parsing an URI isn't that easy, in particular determining the end is undefined AFAIK. In your example the semicolon should probably be considered part of the URI, even though that's obviously not what you intended. Well, we can encode a URI any way we like -- I was thinking of anything up to the next whitespace or semicolon, maybe allowing for balanced brackets; and internal semicolons, etc. being %-encoded. I guess the argument would be that using an encoding that looks almost- but-not-quite like other popular ways of representing URIs could be confusing, and people would be tempted to paste in addresses from their browser without re-encoding them the "P6 way". Maybe it's more practical to permit only URIs with little to no punctuation to be unquoted, and quote anything else? Not that quoting is such a great hardship anyway On 2009-Aug-14, at 7:41 am, Timothy S. Nelson wrote: And in response to David Green and his comment about working with file data vs. metadata, as a systems programmer, I've written a fair number of programs that have worried a fair bit about the metadata in the filesystem; sometimes you want to read data, and sometimes metadata. Of course; and when I referred to "low-level" and "high-level", there isn't really a distinct dividing line between the two. Is getting (or setting) the modification date on a file low-level because it's "metadata", or high-level because it's a simple, "ordinary" task? I don't particularly care about the classification; I just wanted to make the point that P6 should make it possible to gloss over anything that's over-glossable. -David
Re: Filename literals
Richard Hainsworth wrote: Would it be possible to remove the special purpose of \ from strings within IO constructs? This would mean '\' could be used in naming paths as an alternative to '/', thus allowing windows and unix strings to be equivalent, eg. IO(:path<<{$root-path}/data/new>>) would be equivalent to IO(:path<<{$root-path}\data\new>>) The usefulness would be most evident for sub-directories as windows and unix have different ways of describing root, viz. 'C:\' versus '/' I see problems with this considering that \ is quite universally recognized in Perl (and many other languages) as meaning an escape character, and that moreover you generally need to be able to escape characters in any context building a string. Considering that, AFAIK, practically any modern file system, including those used by Windows like NTFS, are Unicode savvy and can have any character in a file name, if \ is used literally to denote itself, then what is a simple clean way to denote other characters that would otherwise be denoted with an escape sequence? I think it would be best, as well as preserving the principle of least surprise, if all of the same escaping syntaxes work universally across character-string-like contexts, which means that a literal \ means escaping. The best compromise that I see is that Windows filenames can be spelled out as Windows people are used to, except that / is used instead of \, so for example a Windows path begins with 'C:/' for example. Or even if the '/' paradigm for root is used in Windows, which may actually be best, the drive letter or drive name still needs to be in the path somewhere so that multiple drives can be distinguished, for example, 'C:\' becomes '/C/'. Under Mac OS X, all drives, root or otherwise, are accessible under '/Volumes//...', and Unix in general lets you mount drives anywhere. I imagine Windows supports more ways of denoting drives than the drive letter, but either way I don't see a problem here. -- Darren Duncan
Re: Filename literals
On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncan wrote: > Under Mac OS X, all drives, root or otherwise, are accessible under > '/Volumes//...', and Unix in general lets you mount drives > anywhere. I imagine Windows supports more ways of denoting drives than the > drive letter. Nope. Have to use the drive letter. But / is understood as a synonym for \ by the Windows API. -- Mark J. Reed
Re: Filename literals
On Aug 14, 2009, at 16:17 , Mark J. Reed wrote: On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncan wrote: Under Mac OS X, all drives, root or otherwise, are accessible under '/Volumes//...', and Unix in general lets you mount drives anywhere. I imagine Windows supports more ways of denoting drives than the drive letter. Nope. Have to use the drive letter. But / is understood as a synonym for \ by the Windows API. UNC drive specs should work as well, i.e.. \\MYHOST\C\... (or swap / for \). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Filename literals
On Fri, Aug 14, 2009 at 7:41 PM, David Green wrote: > Well, we can encode a URI any way we like -- I was thinking of anything up > to the next whitespace or semicolon, and internal semicolons, etc. being > %-encoded. Semicolons are reserved characters in URIs: inappropriately percentage encoding semicolons would be in direct violation of rfc3986. Using them as delimiter would break many perfectly valid URIs. That's absolutely a no-go IMNSHO. Breaking up at whitespace should work, see appendix C of RFC 3986 for recommendations on that. > Maybe it's more practical to permit only URIs with little to no punctuation > to be unquoted, and quote anything else? Not that quoting is such a great > hardship anyway Maybe, but if I can't use it half of the time it may as well be omitted. Quoting should be relatively easy, because URIs have a wide range of characters that can't be in them anyway. Leon
Re: Filename literals
I'll just butt in here and say that while the URI format is nice for alternate schemes, it is not nice for accessing files. The general case in most programming languages is to assume that a non-URI "file" name is local, specifying file://wherever/whatever/filename is unnecessary additional syntax. Also, perhaps only URLs should be permitted; they do after all specify a location. I'm unsure whether this should be part of a central specification to Perl 6 or part of a module. I think I like Hinrik's original proposal. Oh, and regarding file names in Windows, this document should be a pretty definitive guide: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx -- Jan
Re: Filename literals
On Fri, 14 Aug 2009, Darren Duncan wrote: Richard Hainsworth wrote: Would it be possible to remove the special purpose of \ from strings within IO constructs? This would mean '\' could be used in naming paths as an alternative to '/', thus allowing windows and unix strings to be equivalent, eg. IO(:path<<{$root-path}/data/new>>) would be equivalent to IO(:path<<{$root-path}\data\new>>) The usefulness would be most evident for sub-directories as windows and unix have different ways of describing root, viz. 'C:\' versus '/' I see problems with this considering that \ is quite universally recognized in Perl (and many other languages) as meaning an escape character, and that moreover you generally need to be able to escape characters in any context building a string. Considering, though, that we're talking about a magic perl quoting syntax, we could offer people the option of the following two: q:io{C:\Windows} # Does what you want q:io:qq:{C:\\Windows} # Does the same thing Wouldn't that cover the bases pretty well? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On Sat, 15 Aug 2009, Timothy S. Nelson wrote: Considering, though, that we're talking about a magic perl quoting syntax, we could offer people the option of the following two: q:io{C:\Windows} # Does what you want q:io:qq:{C:\\Windows} # Does the same thing Wouldn't that cover the bases pretty well? My bad -- try these: $file = "foo" Q:io{C:\Windows\$file} # Results in "C:\Windows\$file" q:io{C:\\Windows\\$file} # Results in the same thing qq:io{C:\\Windows\\$file} # Results in "C:\Windows\foo" HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
This whole thread seems oriented around two points: 1. Strings should not carry the burden of umpty-ump filesystem checking methods. 2. It should be possible to specify a filesystem entity using something nearly indistinguishable from standard string syntax. I agree with the first, but the relentless pursuit of the second seems to have gone beyond the point of useful speculation. What's wrong with File('C:\Windows') or Path() or Dir() or SpecialDevice()? Not to get all Cozens-y or anything, but chasing after ways to jam some cute string-like overloading into the syntax so that we can pull out the other overloading (which at least had the virtue of simplicity) seems pointless. The File::* functionality is probably going to be one of the very early p6 modules, and it is probably going to be in core. If that's true, why not allocate some really short names, ideally with 0 colons in them, and use them to spell out what's being done? Neither q:io:qq:{.} nor qq:io{.} really stand out at excellent ways to say "this is a path", or directory, or file, or whatever. If it's plug-in-able, I'd take qq:file{.} or qq:dir{.} or qq:path{.}, but I'd rather see C< File q{.} >. =Austin Timothy S. Nelson wrote: On Sat, 15 Aug 2009, Timothy S. Nelson wrote: Considering, though, that we're talking about a magic perl quoting syntax, we could offer people the option of the following two: q:io{C:\Windows} # Does what you want q:io:qq:{C:\\Windows} # Does the same thing Wouldn't that cover the bases pretty well? My bad -- try these: $file = "foo" Q:io{C:\Windows\$file} # Results in "C:\Windows\$file" q:io{C:\\Windows\\$file} # Results in the same thing qq:io{C:\\Windows\\$file} # Results in "C:\Windows\foo" HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On Sat, 15 Aug 2009, Austin Hastings wrote: This whole thread seems oriented around two points: 1. Strings should not carry the burden of umpty-ump filesystem checking methods. 2. It should be possible to specify a filesystem entity using something nearly indistinguishable from standard string syntax. I agree with the first, but the relentless pursuit of the second seems to have gone beyond the point of useful speculation. What's wrong with File('C:\Windows') or Path() or Dir() or SpecialDevice()? Not to get all Cozens-y or anything, but chasing after ways to jam some cute string-like overloading into the syntax so that we can pull out the other overloading (which at least had the virtue of simplicity) seems pointless. The File::* functionality is probably going to be one of the very early p6 modules, and it is probably going to be in core. If that's true, why not allocate some really short names, ideally with 0 colons in them, and use them to spell out what's being done? S32/IO already specifies all these things as living in the IO namespace. That could be changed, of course. Neither q:io:qq:{.} nor qq:io{.} really stand out at excellent ways to say q:io{.} would be the normal case, unless you want variable interpolation or the like. And it would be possible to come up with shorter versions (someone suggested qf). "this is a path", or directory, or file, or whatever. If it's plug-in-able, I'd take qq:file{.} or qq:dir{.} or qq:path{.}, but I'd rather see C< File q{.} >. I'm not particularly attached to :io if we can think of something better. These things often have a short name and a long name. I'm against "file" because the IO::File object models what is inside the file (ie. open/read/write/close/etc), whereas the IO::FSNode/IO::FileNode/IO::DirectoryNode/IO::LinkNode objects model stuff on the outside of the file. It's things of this second type that I'm recommending that we return here. We could change the names of the objects of course, but I'm keen on keeping the class that does stuff to the inside of the file separate from the class that does stuff to the outside of the file. "Path" might be a good alternative in my mind. Anyway, back to the :io name. An alternative might be to have the short name be :p and the long name be :path. That would mean that we could do: q:p{.} That's a fair bit shorter than Path(q{.}). Hmm. Let's compare some code samples: if (q:p'/path/to/file' ~~ :r) { say "Readable\n"; } if (Path('/path/to/file') ~~ :r) { say "Readable\n"; } $fobj = new IO::File(FSNode => q:p'/path/to/file'); $fobj = new IO::File(FSNode => Path('/path/to/file')); I used single quotes for the Path() things because I think that's what people would probably do. Now, say we want to use backslashes. if (Q :p {C:\Windows\file} ~~ :r) { say "Readable\n"; } if (Path(Q {C:\Windows\file}) ~~ :r) { say "Readable\n"; } Ok, so they're comparable. I've used curlies here just because I thought it was a good idea :). Anyway, we have possibilities. Further thoughts anyone? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On Sat, Aug 15, 2009 at 7:17 AM, Timothy S. Nelson wrote: > On Sat, 15 Aug 2009, Austin Hastings wrote: > >> This whole thread seems oriented around two points: >> >> 1. Strings should not carry the burden of umpty-ump filesystem checking >> methods. >> >> 2. It should be possible to specify a filesystem entity using something >> nearly indistinguishable from standard string syntax. >> >> I agree with the first, but the relentless pursuit of the second seems to >> have gone beyond the point of useful speculation. >> >> What's wrong with >> >> File('C:\Windows') >> >> or Path() or Dir() or SpecialDevice()? >> >> Not to get all Cozens-y or anything, but chasing after ways to jam some >> cute string-like overloading into the syntax so that we can pull out the >> other overloading (which at least had the virtue of simplicity) seems >> pointless. >> >> The File::* functionality is probably going to be one of the very early p6 >> modules, and it is probably going to be in core. If that's true, why not >> allocate some really short names, ideally with 0 colons in them, and use >> them to spell out what's being done? > > S32/IO already specifies all these things as living in the IO > namespace. That could be changed, of course. > >> Neither q:io:qq:{.} nor qq:io{.} really stand out at excellent ways to say > > q:io{.} would be the normal case, unless you want variable > interpolation or the like. And it would be possible to come up with shorter > versions (someone suggested qf). > >> "this is a path", or directory, or file, or whatever. If it's >> plug-in-able, I'd take qq:file{.} or qq:dir{.} or qq:path{.}, but I'd rather >> see C< File q{.} >. > > I'm not particularly attached to :io if we can think of something > better. These things often have a short name and a long name. I'm against > "file" because the IO::File object models what is inside the file (ie. > open/read/write/close/etc), whereas the > IO::FSNode/IO::FileNode/IO::DirectoryNode/IO::LinkNode objects model stuff > on the outside of the file. It's things of this second type that I'm > recommending that we return here. We could change the names of the objects > of course, but I'm keen on keeping the class that does stuff to the inside > of the file separate from the class that does stuff to the outside of the > file. "Path" might be a good alternative in my mind. IOW, your "outside the file" stuff is whatever can be done without having to open the file, and your "inside the file" is whatever only makes sense once the file has been opened. Correct? If so, could you give some examples of how such a distinction could be beneficial, or of how the lack of such a distinction is problematic? > Anyway, back to the :io name. An alternative might be to have the > short name be :p and the long name be :path. That would mean that we could > do: > > q:p{.} Isn't there something in the spec that indicates that qq is merely shorthand for q:qq? That is, it's possible to bundle a bunch of quote adverbs together under a special quote name. If so, you might say that q:path and q:p are "longhand" for path: path{.} # same as q:p{.} And yes, 'path' is longer that 'q:p' - but only by one character; and it's considerably more legible. As well, this is more in keeping with what's really going on here: path{.} would be no more a string than m{.} or rx{.} are. In fact, having q, Q, or qq involved at all strikes me as wrong, since those three are specifically for generating strings. Also note the following: "string" # same as qq[string] 'string' # same as q[string] /pattern/ # same as m[pattern]? The ultimate in "path literals" would be to establish a similar "default delimiter". For example, what if the backtick were pressed into service for this purpose? (No, I'm not actually suggesting this; at the very least, there would be p5 false-compatibility issues involved. This is strictly illustrative.) `path` # same as path[path] `path`.e # does that filename exist? Returns boolean. `path`.size # how big is the file? Returns number. `path`.open # Returns new file handle. > That's a fair bit shorter than Path(q{.}). Hmm. Let's compare some > code samples: > > if (q:p'/path/to/file' ~~ :r) { > say "Readable\n"; > } > if (Path('/path/to/file') ~~ :r) { > say "Readable\n"; > } if (path'/path/to/file'.r) { say "Readable"; } if (`/path/to/file`.r) { say "Readable"; } > $fobj = new IO::File(FSNode => q:p'/path/to/file'); > $fobj = new IO::File(FSNode => Path('/path/to/file')); $fobj = path[/path/to/file].open; $fobj = `/path/to/file`.open; > I used single quotes for the Path() things because I think that's > what people would probably do. > > Now, say we want to use backslashes. > > if (Q :p {C:\Windows\file} ~~ :r) { > say "Readable\n"; > } > if (Path(Q {C:\Windows\file}) ~~ :r) { > say "Readable\n"; > } if (path:win[C:\Windows\file].r)
Re: Filename literals
On 2009-Aug-15, at 9:22 am, Jon Lang wrote: IOW, your "outside the file" stuff is whatever can be done without having to open the file, and your "inside the file" is whatever only makes sense once the file has been opened. Correct? If so, could you give some examples of how such a distinction could be beneficial, or of how the lack of such a distinction is problematic? Well, I definitely think there needs to be a class that combines the inside and the outside, or the data and the metadata. Certainly the separate parts will exist separately for purposes of implementation, but there needs to be a user-friendlier view wrapped around that. Or maybe there are (sort of) three levels, low, medium, and high; that is, the basic implementation level (=P6 direct access to OS- and FS- system calls); the combined level, where an IO or "File" object encompasses IO::FSnode and IO::FSdata, etc.; and a gloss-over-the- details level with lots of sugar on top (at the expense of losing control over some details). In fact, having q, Q, or qq involved at all strikes me as wrong, since those three are specifically for generating strings. Pathnames still are strings, so that's fine. In fact, there are different things going on here; one is to have a way of conveniently quoting strings that contain a lot of backslashes. Just as Perl lets you pick different quotation marks, to make it easier to quote strings that have a lot of " or ' characters, so it should have a way to make it easy to quote strings with a lot of backslashes. (The most obvious example being Windows paths; but there are other possibilities, such as needing to eval some code that already has a lot of backslashes in it.) Now, you can already turn backwhacking on or off via Q's :backslash adverb; Q:qq includes :b (and Q:q recognises a few limited escape sequences like \\). So you could say Q[C:\some\path], and you could add scalar interpolation to say Q:s[C:\some\path\$filename]. But there's no way to have all of: literal backslashes + interpolation + escaped sigils. Perhaps instead of a simple :b toggle, we could have an :escape adverb that defaults to :escape<\>? Then you could have Q:scalar:escape("^")[C:\path\with\literal^$\$filename]. The ultimate in "path literals" would be to establish a similar "default delimiter". [...] `path`.size # how big is the file? Returns number. There's something that slightly jars me here... I don't like the quotation returning an IO object. (I like the conciseness, but there's something a bit off conceptually.) Let's see, `exec command` bugs me too -- it's quoting something and then doing something with the quoted string. (It's not entirely unreasonable as a cryptic shorthand in the shell, but I think P6 should have an actual command for that (e.g. the proposed run-gather()).) Similarly, in this example, we're quoting a pathname, and then creating an IO object from it. So I don't like the quoting-and-then-using, when done by the quotation marks, although having a function (really, macro) that does its own quoting seems fine: "io /some/autoquoted/filename". And /regex/ doesn't bother me either. Hm. Ah, but an instant regex isn't doing anything besides creating an object -- it is comparable to q[foo] creating a Str. So `exec me!` bothers me because it isn't just returning some kind of "System::Command" object, it's more like creating the object and then calling the .run() method on it too. / pattern/ doesn't *do* anything with the regex. Now, isn't Q:path[/some/file] just creating an IO object? Unlike / foo/, where "foo" just IS the pattern, "/some/file" is *not* an IO object, it's just a filename. So if the special path-quoting returned an IO::File::Name object, I would be perfectly happy. But you can't have $filename.size -- a fileNAME doesn't have a size, the file itself does. To get from the filename to the file, you need another step, and it's that extra step I don't like being hidden inside quotation marks, just as in the `exec` case. Anyway, that's a subtle but important point, I think. Fortunately, in the end it doesn't have to work out much differently: instead a "path" quoter that does IO-stuff, have a "path" function (macro, whatever) that does quoting stuff. $file = new IO::File(FSNode => "/path/to/file"); $file = path "/path/to/file"; $file = io /path/to/file; $file = file://localhost/path/to/file; Incidentally, I do think it's worth having an actual File::Name type, even though names are really just strings. For example, not all strings are valid filenames if the FS doesn't handle Unicode. However, Strings should get transparently cast to IO::Names wherever possible, so the typical user would never have to notice the difference. IO::Name objects also provide a way to concatenate items correctly, as per Hinrik's original post regarding a be
Re: Filename literals
On Sun, 16 Aug 2009, David Green wrote: On 2009-Aug-15, at 9:22 am, Jon Lang wrote: IOW, your "outside the file" stuff is whatever can be done without having to open the file, and your "inside the file" is whatever only makes sense once the file has been opened. Correct? Pretty much, yes. If so, could you give some examples of how such a distinction could be beneficial, or of how the lack of such a distinction is problematic? Well, my main thought in this context is that the stuff that can be done to the inside of a file can also be done to other streams -- TCP sockets for example (I know, there are differences, but the two are a lot the same), whereas metadata makes less sense in the context of TCP sockets; I guess this was one of the thoughts that led me to want separate things here. Well, I definitely think there needs to be a class that combines the inside and the outside, or the data and the metadata. Certainly the separate parts will exist separately for purposes of implementation, but there needs to be a user-friendlier view wrapped around that. Or maybe there are (sort of) three levels, low, medium, and high; that is, the basic implementation level (=P6 direct access to OS- and FS- system calls); the combined level, where an IO or "File" object encompasses IO::FSnode and IO::FSdata, etc.; and a gloss-over-the-details level with lots of sugar on top (at the expense of losing control over some details). Hmm. With the quoting idea, I don't see the need for a "both" type of object. I mean, I'd see the code happening something like this: if (path{/path/to/file}.e) { @lines = slurp(path{/path/to/file}); } Or... if (path{/path/to/file}.e) { $handle = open(path{/path/to/file}); } (I'm using one of David's suggested syntaxes above, but I'm not closely attached to it). I guess what I'm saying here is that I think we can do the things without people having to worry about the objects being separate unless they care. So, separate objects, but hide it as much as possible. Is that something you're fine with? In fact, having q, Q, or qq involved at all strikes me as wrong, since those three are specifically for generating strings. Pathnames still are strings, so that's fine. In fact, there are different Hmm. I'm not so sure; maybe I'm just being picky, but I want to clarify things in case it's important (in other words, I'm thinking out loud here to see if it helps). First, Q and friends don't generate strings, they generate string-like objects, which could be Str, or Match, or whatever. Think of quoting constructs as a way of temporarily switching to a different sublanguage (cf. regex), and you'll have the idea that I have in mind. As for pathnames being strings, you may be right FSVO string. But I'd say that, while they may be strings, they're not Str, but they do Str, as in roleIO::FSNode does Str {...} (FSNode may not be the right name here, but is used for illustrative purposes). things going on here; one is to have a way of conveniently quoting strings that contain a lot of backslashes. Just as Perl lets you pick different quotation marks, to make it easier to quote strings that have a lot of " or ' characters, so it should have a way to make it easy to quote strings with a lot of backslashes. (The most obvious example being Windows paths; but there are other possibilities, such as needing to eval some code that already has a lot of backslashes in it.) Now, you can already turn backwhacking on or off via Q's :backslash adverb; Q:qq includes :b (and Q:q recognises a few limited escape sequences like \\). So you could say Q[C:\some\path], and you could add scalar interpolation to say Q:s[C:\some\path\$filename]. But there's no way to have all of: literal backslashes + interpolation + escaped sigils. Perhaps instead of a simple :b toggle, we could have an :escape adverb that defaults to :escape<\>? Then you could have Q:scalar:escape("^")[C:\path\with\literal^$\$filename]. Maybe a global variable? It's an interesting idea, and I'll see how others feel :). The ultimate in "path literals" would be to establish a similar "default delimiter". [...] `path`.size # how big is the file? Returns number. There's something that slightly jars me here... I don't like the quotation returning an IO object. (I like the conciseness, but there's something a bit off conceptually.) Hmm. But doesn't normal quoting return a Str object? And regex quoting return an object (Regex? Match? Something, anyway). Now, isn't Q:path[/some/file] just creating an IO object? Unlike /foo/, where "foo" just IS the pattern, "/some/file" is *not* an IO object, it's just a filename. So if the special path-quoting returned an IO::File::Name object, I would be perfectly happy. But you can't have $filename.size -- a fileNAME doesn't have a size, the file itself does. To get from the fil
Re: Filename literals
Timothy S. Nelson wrote: > David Green wrote: >> Jon Lang wrote: >>> If so, could you give some examples of how such a distinction could be >>> beneficial, or of how the lack of such a distinction is problematic? > > Well, my main thought in this context is that the stuff that can be > done to the inside of a file can also be done to other streams -- TCP > sockets for example (I know, there are differences, but the two are a lot > the same), whereas metadata makes less sense in the context of TCP sockets; > I guess this was one of the thoughts that led me to want separate things > here. Ah. I can see that. >> Well, I definitely think there needs to be a class that combines the >> inside and the outside, or the data and the metadata. Certainly the >> separate parts will exist separately for purposes of implementation, but >> there needs to be a user-friendlier view wrapped around that. Or maybe >> there are (sort of) three levels, low, medium, and high; that is, the basic >> implementation level (=P6 direct access to OS- and FS- system calls); the >> combined level, where an IO or "File" object encompasses IO::FSnode and >> IO::FSdata, etc.; and a gloss-over-the-details level with lots of sugar on >> top (at the expense of losing control over some details). > > Hmm. With the quoting idea, I don't see the need for a "both" type > of object. I mean, I'd see the code happening something like this: > > if (path{/path/to/file}.e) { > �...@lines = slurp(path{/path/to/file}); > } > > Or... > > if (path{/path/to/file}.e) { > $handle = open(path{/path/to/file}); > } > > > > (I'm using one of David's suggested syntaxes above, but I'm not > closely attached to it). For the record, the above syntax was my suggestion. > I guess what I'm saying here is that I think we can do the things > without people having to worry about the objects being separate unless they > care. So, separate objects, but hide it as much as possible. Is that > something you're fine with? It looks good to me. >>> In fact, having q, Q, or qq involved at all strikes me as wrong, >>> since those three are specifically for generating strings. >> >> Pathnames still are strings, so that's fine. In fact, there are different > > Hmm. I'm not so sure; maybe I'm just being picky, but I want to > clarify things in case it's important (in other words, I'm thinking out loud > here to see if it helps). > > First, Q and friends don't generate strings, they generate > string-like objects, which could be Str, or Match, or whatever. Think of > quoting constructs as a way of temporarily switching to a different > sublanguage (cf. regex), and you'll have the idea that I have in mind. > > As for pathnames being strings, you may be right FSVO string. But > I'd say that, while they may be strings, they're not Str, but they do Str, > as in > > role IO::FSNode does Str {...} > > (FSNode may not be the right name here, but is used for illustrative > purposes). I'd go one step further. Consider the Windows path 'C:\Program Files\'. Is the string what's really important, or is it the directory to which the string refers? I ask because, for legacy reasons, the following points to the same directory: 'C:\PROGRA~1\'. Then there's the matter of absolute and relative paths: if the current working directory is 'C:\Program Files\', then the path 'thisfile' actually refers to 'C:\Program Files\thisfile'. And because of parent directory and self-reference links, things like '/bin/../etc/.' is just an overcomplicated way of pointing to '/etc'. I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings. >> things going on here; one is to have a way of conveniently quoting strings >> that contain a lot of backslashes. Just as Perl lets you pick different >> quotation marks, to make it easier to quote strings that have a lot of " or >> ' characters, so it should have a way to make it easy to quote strings with >> a lot of backslashes. (The most obvious example being Windows paths; but >> there are other possibilities, such as needing to eval some code that >> already has a lot of backslashes in it.) >> >> Now, you can already turn backwhacking on or off via Q's :backslash >> adverb; Q:qq includes :b (and Q:q recognises a few limited escape sequences >> like \\). So you could say Q[C:\some\path], and you could add scalar >> interpolation to say Q:s[C:\some\path\$filename]. But there's no way to >> have all of: literal backslashes + interpolation + escaped sigils. >> >> Perhaps instead of a simple :b toggle, we could have an :escape >> adverb that defaults to :escape<\>? Then you could have >> Q:scalar:escape("^")[C:\path\with\literal^$\$filename]. > > Maybe a global variable? It's an
Re: Filename literals
Hey, Just joined the list, and I too have been thinking about a good path literal for Perl 6. Nice to see so many other people are thinking the same :). Not knowing where to start in this long thread, I will instead try to show how I would like a path literal to work. For me a path literal is a way to make the code pretty and clean. And for multi platform coding this is mostly where it gets hard to do. So I think a path literal should make it possible to use both a native style and a more modern portable one, without having to give up using spaces like in Path::Spec from Perl 5 or have to do verbose object creation. First I think extending Q with a Q:path{} and making the alias Q:p{} and p{} would be the most consistent with the current string literal API. Also it should be possible to sub type the literals to further limit format and content. This should be done so we can get compile time error when path's are know to be incorrect or that we throw an exception or return a undef with an error type(or whatever Larry called it) when we interpolate and return something that is known to be incorrect. The default p{} should only allow "/" as separator and should not allow characters that won't work on modern Windows and Unix like \ / ? % * : | " > <, etc. The reason for this is that portable Path's should be the default and if you really need platform specific behavior it should be shown in the code. my Path $path = p{../ext/dictonary.txt}; or my Path $path = p{c:/ext/dictonary.txt}; We should allow windows style paths so converting and maintaining code on this platform is not a pain. my Path $path = p:win{C:\Program Files\MS Access\file.file}; For Unix specific behavior we should have a p:unix{} literal, here the only limit are what is defined by locale. So we won't be able to write full Unicode if locale is set to Latin1. Writing filenames to the filesystem that other programs won't be able to read should be hard. my Path $path = p:unix{/usr/src/bla/myfile?:%.file}; And for people where this is a problem p:bin{} can be used as no checking is done here. my $path = p:bin{/usr/src/bla/??/adasd/myfile}; Old style Mac paths could also be supported where the : is used as separator. my Path $path = p:mac{usr:src:bla}; Or old dos paths where 8 char limits and all the old dos stuff apply. my Path $path = p:dos{c:\windows\test.fil}; Urls could also be support with: my Path $path = p:url{file:///home/test.file} ** Path Object like File::Spec, etc. just nicer ** All the different variants for p{} return a Path object that offers much of what is found in File::Spec, Cwd and Path::Class in Perl 5 today in a more Perl 6 way. my Path $real_path = $path.realpath; # Like Cwd's realpath my Path $volume = $path.volume; # Returns the volume part if relevant my Path $dir = $path.dir; # Returns the directory part my Path $file = $path.file; # Returns the file part $path.shift(); # Get rid of last part of path $path.pop(); # Get rid of first part or path my @paths = $path.dirs; # Returns the directory parts of the path etc. ** Comparing Paths should do the right thing ** As we have the option of specifying what type a Path object is, this should also count when comparing the them. So fx. p:win{} are case insensitive. my $file = p:win{c:\My File.txt}; my $path = p:win{C:\Program Files\..}; if($path.is_in($file)) { # Check if the path is contained in another path say "$file is in $path\n"; # C:\My File.txt is C: } if(p{../test} ~~ p{../dir/../test}) { say "Comparing two Path works as it should"; } Also Path handles Unicode normalization so this won't be a problem: http://lists.zerezo.com/git/msg643117.html Meaning that both "Mrchen" and "Marchen" are the same path, but without normalizing the path behind the users back. ** Utility functions ** Path in itself knows nothing about the filesystem and files but might have a peek in $*CWD to do some path logic. Except for that a number of File related functions might be available to make it easy to open and slurp a file a Path points to. my File $file = p{/etc/passwd}.open; if($file.type ~~ 'text/plain') { say "looks like a password file"; } my @passwd = p{/etc/passwd}.lines; if(p{/etc/passwd}.exists) { say "passwd file exists"; } This is my thought so far, hope it helps the discussion. Regards Troels
Re: Filename literals
Troels Liebe Bentsen wrote: > Hey, > > Just joined the list, and I too have been thinking about a good path literal > for Perl 6. Nice to see so many other people are thinking the same :). Welcome to the list! > Not knowing where to start in this long thread, I will instead try to show how > I would like a path literal to work. A well-considered proposal, and one with which I mostly agree. Some thoughts: > The default p{} should only allow "/" as separator and should not allow > characters that won't work on modern Windows and Unix like \ / ? % * : | " > > <, > etc. The reason for this is that portable Path's should be the default and if > you really need platform specific behavior it should be shown in the code. I note that you explicitly included * and ? in the list of forbidden characters; I take it, then, that you're not in favor of Path as a glob-based pattern-matching utility? E.g.: my Path $path; ... unless $path ~~ p { say "the file doesn't begin with 'astro'". } Admittedly, this particular example _could_ be accomplished through the use of a regex; but there _are_ cases where the use of wildcard characters would be easier than the series of equivalent tests that Perl would otherwise have to perform in order to achieve the same result. Hmm... maybe we need something analogous to q vs. qq; that is: p #`{ syntax error: '*' is not a valid filename character. } pp #`{ returns an object that is used for Path pattern-matching; perhaps Pathglob or somesuch? } > We should allow windows style paths so converting and maintaining code on this > platform is not a pain. : > For Unix specific behavior we should have a p:unix{} literal, here the only > limit are what is defined by locale. : > And for people where this is a problem p:bin{} can be used as no checking is > done here. : > Old style Mac paths could also be supported where the : is used as separator. : > Or old dos paths where 8 char limits and all the old dos stuff apply. Hear, hear. Note that these are all mutually exclusive, which suggests that the proper format ought to be something like: my Path $path = p:format{C:\Program Files} However, I have no problem with the idea that :win is short for :format; the feature here is brevity. > Urls could also be support with: > > my Path $path = p:url{file:///home/test.file} I would be very careful here, in that I wouldn't want to open the can of worms inherent in non-file protocols (e.g., ftp, http, gopher, mail), or even in file protocols with hosts other than localhost. > ** Path Object like File::Spec, etc. just nicer ** : > ** Comparing Paths should do the right thing ** Agreed on all counts. > ** Utility functions ** > > Path in itself knows nothing about the filesystem and files but might have a > peek in $*CWD to do some path logic. Except for that a number of File related > functions might be available to make it easy to open and slurp a file a Path > points to. > > my File $file = p{/etc/passwd}.open; > if($file.type ~~ 'text/plain') { > say "looks like a password file"; > } > > my @passwd = p{/etc/passwd}.lines; > > > if(p{/etc/passwd}.exists) { > say "passwd file exists"; > } As soon as you allow methods such as .exists, it undermines your claim that Path knows nothing about the filesystem or files. IMHO, you should still include such methods. -- Jonathan "Dataweaver" Lang
Re: Filename literals
On Mon, 17 Aug 2009, Jon Lang wrote: Well, I definitely think there needs to be a class that combines the inside and the outside, or the data and the metadata. Certainly the separate parts will exist separately for purposes of implementation, but there needs to be a user-friendlier view wrapped around that. Or maybe there are (sort of) three levels, low, medium, and high; that is, the basic implementation level (=P6 direct access to OS- and FS- system calls); the combined level, where an IO or "File" object encompasses IO::FSnode and IO::FSdata, etc.; and a gloss-over-the-details level with lots of sugar on top (at the expense of losing control over some details). Hmm. With the quoting idea, I don't see the need for a "both" type of object. I mean, I'd see the code happening something like this: if (path{/path/to/file}.e) { �...@lines = slurp(path{/path/to/file}); } Or... if (path{/path/to/file}.e) { $handle = open(path{/path/to/file}); } (I'm using one of David's suggested syntaxes above, but I'm not closely attached to it). For the record, the above syntax was my suggestion. Ok, as long as I don't have to take the blame :). Seriously, I was confused by trying to reply to two e-mails at once. Sorry. In fact, having q, Q, or qq involved at all strikes me as wrong, since those three are specifically for generating strings. Pathnames still are strings, so that's fine. In fact, there are different Hmm. I'm not so sure; maybe I'm just being picky, but I want to clarify things in case it's important (in other words, I'm thinking out loud here to see if it helps). First, Q and friends don't generate strings, they generate string-like objects, which could be Str, or Match, or whatever. Think of quoting constructs as a way of temporarily switching to a different sublanguage (cf. regex), and you'll have the idea that I have in mind. As for pathnames being strings, you may be right FSVO string. But I'd say that, while they may be strings, they're not Str, but they do Str, as in role IO::FSNode does Str {...} (FSNode may not be the right name here, but is used for illustrative purposes). I'd go one step further. Consider the Windows path 'C:\Program Files\'. Is the string what's really important, or is it the directory to which the string refers? I ask because, for legacy reasons, the following points to the same directory: 'C:\PROGRA~1\'. Then there's the matter of absolute and relative paths: if the current working directory is 'C:\Program Files\', then the path 'thisfile' actually refers to 'C:\Program Files\thisfile'. And because of parent directory and self-reference links, things like '/bin/../etc/.' is just an overcomplicated way of pointing to '/etc'. I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings. Good ideas. But I still want it to have the same interface, so I can concatenate them easily in error messages :). things going on here; one is to have a way of conveniently quoting strings that contain a lot of backslashes. Just as Perl lets you pick different quotation marks, to make it easier to quote strings that have a lot of " or ' characters, so it should have a way to make it easy to quote strings with a lot of backslashes. (The most obvious example being Windows paths; but there are other possibilities, such as needing to eval some code that already has a lot of backslashes in it.) Now, you can already turn backwhacking on or off via Q's :backslash adverb; Q:qq includes :b (and Q:q recognises a few limited escape sequences like \\). So you could say Q[C:\some\path], and you could add scalar interpolation to say Q:s[C:\some\path\$filename]. But there's no way to have all of: literal backslashes + interpolation + escaped sigils. Perhaps instead of a simple :b toggle, we could have an :escape adverb that defaults to :escape<\>? Then you could have Q:scalar:escape("^")[C:\path\with\literal^$\$filename]. Maybe a global variable? It's an interesting idea, and I'll see how others feel :). I'm leery of global variables, per se; but I _do_ like the idea of lexically-scoped options that let you customize the filename syntax. Changing the default delimiter would be the most common example of this. Yeah, global variable is probably a bad idea. But it *feels* like it should be some kind of global or semi-global setting :). By "semi-global", I mean something that you can override in your local scope, and have it revert, much as with the $*IN, etc, filehandles. Now, isn't Q:path[/some/file] just creating an IO object? Unlike /foo/, where "foo" just IS the pattern, "/some/file" is *not* an IO object, it's just a filename. So if the special path-quoting returned an
Re: Filename literals
On Mon, Aug 17, 2009 at 23:11, Jon Lang wrote: >> The default p{} should only allow "/" as separator and should not allow >> characters that won't work on modern Windows and Unix like \ / ? % * : | " > >> <, >> etc. The reason for this is that portable Path's should be the default and if >> you really need platform specific behavior it should be shown in the code. > > I note that you explicitly included * and ? in the list of forbidden > characters; I take it, then, that you're not in favor of Path as a > glob-based pattern-matching utility? E.g.: > >my Path $path; > ... >unless $path ~~ p { say "the file doesn't begin with 'astro'". } > > Admittedly, this particular example _could_ be accomplished through > the use of a regex; but there _are_ cases where the use of wildcard > characters would be easier than the series of equivalent tests that > Perl would otherwise have to perform in order to achieve the same > result. Hmm... maybe we need something analogous to q vs. qq; that > is: > >p #`{ syntax error: '*' is not a valid filename character. } >pp #`{ returns an object that is used for Path > pattern-matching; perhaps Pathglob or somesuch? } Glob's are special and should properly have it's own sub format, the problem of including * and ? in Path's is that on Unix this is a allowed file system name. Q:glob{} and g{} might be nice. Buy then again as * and ? is disallowed for the default portable p{}, using any of these might make it return a PathGlob instead. But I think an glob interpolating pp{} might be the best solution, so the default p{} is strict and returns and error. my Path $path = p{file.txt}; my PathGlob $pathglob = pp{*.txt}; Allowing code like this: for(pp{*.txt}.open -> $file) { my @lines = $file.lines; } >> Urls could also be support with: >> >> my Path $path = p:url{file:///home/test.file} > > I would be very careful here, in that I wouldn't want to open the can > of worms inherent in non-file protocols (e.g., ftp, http, gopher, > mail), or even in file protocols with hosts other than localhost. You are properly right, but then again if it's not up to Path to actual know how to open or work with the file/url. It would only have to know the rules for how urls work not how to open them. In it's basic form Path should not be able to do any IO. But I'm not too sure URL's belong in Path. >> ** Utility functions ** >> >> Path in itself knows nothing about the filesystem and files but might have a >> peek in $*CWD to do some path logic. Except for that a number of File related >> functions might be available to make it easy to open and slurp a file a Path >> points to. >> >> my File $file = p{/etc/passwd}.open; >> if($file.type ~~ 'text/plain') { >> say "looks like a password file"; >> } >> >> my @passwd = p{/etc/passwd}.lines; >> >> >> if(p{/etc/passwd}.exists) { >> say "passwd file exists"; >> } > > As soon as you allow methods such as .exists, it undermines your claim > that Path knows nothing about the file system or files. IMHO, you > should still include such methods. My idea with the utility functions are that they are merely wrappers or pretty syntax for using the build in IO call. So if fx. url paths where included in the spec, most of these functions would be provided by libraries handling the IO. How this can be done in a nice OO way, I don't know, but I'm sure people a lot smarter than me can figure that out. Regards Troels
Re: Filename literals
On Tue, 18 Aug 2009, Troels Liebe Bentsen wrote: Glob's are special and should properly have it's own sub format, the problem of including * and ? in Path's is that on Unix this is a allowed file system name. Agreed about the subformat, but I think the "glob" function is sufficient in this case. I mean, I can think of a number of other sublanguages that could be given their own quoting format (sprintf, pack/unpack, Form.pm), but I don't think it's a good idea giving everything its own format -- I'd be happy to keep glob as just a function. Urls could also be support with: my Path $path = p:url{file:///home/test.file} I would be very careful here, in that I wouldn't want to open the can of worms inherent in non-file protocols (e.g., ftp, http, gopher, mail), or even in file protocols with hosts other than localhost. You are properly right, but then again if it's not up to Path to actual know how to open or work with the file/url. It would only have to know the rules for how urls work not how to open them. In it's basic form Path should not be able to do any IO. But I'm not too sure URL's belong in Path. That's why we have the %*PROTOCOLS global variable, so that we can figure out what to do with the various protocols. ** Utility functions ** Path in itself knows nothing about the filesystem and files but might have a peek in $*CWD to do some path logic. Except for that a number of File related functions might be available to make it easy to open and slurp a file a Path points to. my File $file = p{/etc/passwd}.open; if($file.type ~~ 'text/plain') { say "looks like a password file"; } my @passwd = p{/etc/passwd}.lines; if(p{/etc/passwd}.exists) { say "passwd file exists"; } As soon as you allow methods such as .exists, it undermines your claim that Path knows nothing about the file system or files. IMHO, you should still include such methods. I don't know if I mentioned it, but I claim that the Path should also handle metadata as well as the actual path logic. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On 2009-Aug-17, at 8:36 am, Jon Lang wrote: Timothy S. Nelson wrote: Well, my main thought in this context is that the stuff that can be done to the inside of a file can also be done to other streams -- TCP sockets for example (I know, there are differences, but the two are a lot the same), whereas metadata makes less sense in the context of TCP sockets; But any IO object might have metadata; some different from the metadata you traditionally get with files, and some the same, e.g. $io.size, $io.times{modified}, $io.charset, $io.type. if (path{/path/to/file}.e) { @lines = slurp(path{/path/to/file}); } (I'm using one of David's suggested syntaxes above, but I'm not closely attached to it). I suggested variations along the line of: io "/path/to/file". It amounts to much the same thing, but it's important conceptually to distinguish a pathname from the thing it names. (A path doesn't have a modification date, a file does.) Also, special quoting/escaping could apply to other things, not limited to "filenames". That said, I don't think it's unreasonable to want to combine both operations for brevity, but the io-constructor should have built-in path parsing, not the other way around. I guess what I'm saying here is that I think we can do the things without people having to worry about the objects being separate unless they care. So, separate objects, but hide it as much as possible. Is that something you're fine with? Yes -- to me that means some class/role that wraps up all the pieces together, but all the separate components are still there underneath. But I'm not too bothered about how it's implemented as long as it's transparent for casual use. my $file = io p[/some/file]; my $contents = $file.data; my $mod-date = $file.times{modified}; my $size = $file.size; Pathnames still are strings, so that's fine. In fact, there are different As for pathnames being strings, you may be right FSVO string. But I'd say that, while they may be strings, they're not Str, but they do Str Agreed, pathnames are "almost" strings, but worth distinguishing conceptually. There should be a URL type that does Str. Actually, there are other differences, like case-insensitivity and illegal chars. Unfortunately, those depend on the given filesystem. As long as you're dealing with one FS at a time, that's OK; it probably means we have IO::Name::ext3, IO::Name::NTFS, IO::Name::HFS, etc. But what happens when you cross FS-barriers? Does a case- sensitive name match a case-insensitive one? Is filename-equality not commutative or not transitive? If you're looking for a filename "foo" on Mac/Win, then a file actually called "FOO" matches; but on Unix it wouldn't. (Actually, Macs can do both IO::Name::HFS::case-insensitive and IO::Name::HFS::case-sensitive. Eek.) I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings. Well, the *files* are the same, but the pathnames are different. I'm not sure whether some differences in "spelling" should be ignored by default or not. There are actually several different kinds; S32 has a method "realpath", but I think "canonical" is a better name, because aliases can be just as "real" as the canonical path, e.g. a web page with multiple addresses. Or hard links rather than soft links -- though in that case, there is no one "canonical" path. It may not even be possible to easily tell if there is one or not. Some ways in which different paths can be considered equivalent: Spelling: C:\PROGRA~1, case-insensitivity Simplification: foo/../bar/ to bar/ Resolution: of symlinks/shortcuts Content-wise: hard links/multiple addresses Depending on the circumstances, you might want any of those to count as the "same" file; or none of them. We'll need methods for each sort of transformation, $path.canonical, $path.normalize, $path.simplify, etc. Two high-level IO objects are "the same", regardless of path, if $file2 =:= $file2 (which might compare inodes, etc.). There should be a way to set what level of sameness applies in a given lexical scope; perhaps the first two listed above are a reasonable default to start with. There's something that slightly jars me here... I don't like the quotation returning an IO object. But doesn't normal quoting return a Str object? And regex quoting return an object (Regex? Match? Something, anyway). Certainly, but a regex doesn't produce a Signature object, say. I don't object to objects, just to creating objects, then doing something with them, then returning another kind of object, and calling that "parsing". If we're parsing the characters, we should en
Re: Filename literals
Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. The only sane way to deal with filenames is treating them as opaque binary strings, making any more assumptions is bound to get you into trouble. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. Portability should be positive, not negative IMNSHO. As for comparing paths: reimplementing logic that belongs to the filesystem sounds like really Bad Idea™ to me. Two paths can't be reliably compared without choosing to make some explicit assumptions, and I don't think Perl should make such choices for the programmer. Leon Timmermans
Re: Filename literals
On Tue, 18 Aug 2009, David Green wrote: On 2009-Aug-17, at 8:36 am, Jon Lang wrote: Timothy S. Nelson wrote: Well, my main thought in this context is that the stuff that can be done to the inside of a file can also be done to other streams -- TCP sockets for example (I know, there are differences, but the two are a lot the same), whereas metadata makes less sense in the context of TCP sockets; But any IO object might have metadata; some different from the metadata you traditionally get with files, and some the same, e.g. $io.size, $io.times{modified}, $io.charset, $io.type. Ok, now you're giving me ideas :). [snipped a bit and moved it further down the e-mail] I guess what I'm saying here is that I think we can do the things without people having to worry about the objects being separate unless they care. So, separate objects, but hide it as much as possible. Is that something you're fine with? Yes -- to me that means some class/role that wraps up all the pieces together, but all the separate components are still there underneath. But I'm not too bothered about how it's implemented as long as it's transparent for casual use. my $file = io p[/some/file]; my $contents = $file.data; my $mod-date = $file.times{modified}; my $size = $file.size; That sounds like the kind of thing I'm heading for. Pathnames still are strings, so that's fine. In fact, there are different As for pathnames being strings, you may be right FSVO string. But I'd say that, while they may be strings, they're not Str, but they do Str Agreed, pathnames are "almost" strings, but worth distinguishing conceptually. There should be a URL type that does Str. Actually, there are other differences, like case-insensitivity and illegal chars. Unfortunately, those depend on the given filesystem. As long as you're dealing with one FS at a time, that's OK; it probably means we have IO::Name::ext3, IO::Name::NTFS, IO::Name::HFS, etc. But what happens when you cross FS-barriers? Does a case-sensitive name match a case-insensitive one? Is filename-equality not commutative or not transitive? If you're looking for a filename "foo" on Mac/Win, then a file actually called "FOO" matches; but on Unix it wouldn't. (Actually, Macs can do both IO::Name::HFS::case-insensitive and IO::Name::HFS::case-sensitive. Eek.) I think it should depend on the set of constraints involved. I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings. Well, the *files* are the same, but the pathnames are different. I'm not sure whether some differences in "spelling" should be ignored by default or not. There are actually several different kinds; S32 has a method "realpath", but I think "canonical" is a better name, because aliases can be just as "real" as the canonical path, e.g. a web page with multiple addresses. Or hard links rather than soft links -- though in that case, there is no one "canonical" path. It may not even be possible to easily tell if there is one or not. Some ways in which different paths can be considered equivalent: Spelling: C:\PROGRA~1, case-insensitivity Simplification: foo/../bar/ to bar/ Resolution: of symlinks/shortcuts Content-wise: hard links/multiple addresses Depending on the circumstances, you might want any of those to count as the "same" file; or none of them. We'll need methods for each sort of transformation, $path.canonical, $path.normalize, $path.simplify, etc. Two high-level IO objects are "the same", regardless of path, if $file2 =:= $file2 (which might compare inodes, etc.). There should be a way to set what level of sameness applies in a given lexical scope; perhaps the first two listed above are a reasonable default to start with. Ok, my next commit will have "canonpath" (stolen directly from p5's File::Spec documentation), which will do "No physical check on the filesystem, but a logical cleanup of a path", and "realpath" (idea taken from p5's Cwd documentation), which will resolve symlinks, etc, and provide an absolute path. Oh, and "resolvepath", which does both. I'm not quite sure I followed all your discussion above -- have I left something out? Anyway, my assumption is that there should be a number of comparison options. Since we do Str, we should get string comparison for free. But I'm expecting other options at other levels, but have no idea how or what at this point. There's something that slightly jars me here... I don't like the quotation returning an IO object. But doesn't normal quoting return a Str object? And regex quoting return an object (Regex? Match? Something, anyway). Certainly, but a regex doesn't produce a Signature object, say. I don't object to objec
Re: Filename literals
Leon (>): > Reading this discussion, I'm getting the feeling that filename > literals are increasingly getting magical, something that I don't > think is a good development. The only sane way to deal with filenames > is treating them as opaque binary strings, making any more assumptions > is bound to get you into trouble. I don't want to deal with Windows' > strange restrictions on characters when I'm working on Linux. I don't > want to deal with any other platform's particularities either. > Portability should be positive, not negative IMNSHO. > > As for comparing paths: reimplementing logic that belongs to the > filesystem sounds like really Bad Idea™ to me. Two paths can't be > reliably compared without choosing to make some explicit assumptions, > and I don't think Perl should make such choices for the programmer. Very nicely put. We can't predict the future, but in creating something that'll at least persist through the next decade, let's not do elaborate things with lots of moving parts. Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. To quote Kernighan and Pike: Simplicity. Clarity. Generality. I agree. magic can always be added with module goodness // Carl
Re: Filename literals
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak wrote: > > Let's make a solid ground to stand on; something so stable that it > works uphill and underwater. People with expertise and tuits will > write the facilitating modules. > > To quote Kernighan and Pike: Simplicity. Clarity. Generality. > I agree. > magic can always be added with module goodness > I agree with this principle. The discussion has been (and probably still will be) fruitful anyway, if only in illuminating the challenges with multi-platform and multi-filesystem support, some of the things we need to consider for that and how. -- Jan
Re: Filename literals
+1 Carl Mäsak wrote: Very nicely put. We can't predict the future, but in creating something that'll at least persist through the next decade, let's not do elaborate things with lots of moving parts. Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. To quote Kernighan and Pike: Simplicity. Clarity. Generality. I agree. magic can always be added with module goodness
Re: Filename literals
On Tue, 18 Aug 2009, Leon Timmermans wrote: Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. The only sane way to deal with filenames is treating them as opaque binary strings, making any more assumptions is bound to get you into trouble. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. Portability should be positive, not negative IMNSHO. Sounds to me like you need p:bin{/path/to/file} -- that does what you want it to. I'll make it more obvious in the S16 documentation. As for comparing paths: reimplementing logic that belongs to the filesystem sounds like really Bad Idea? to me. Two paths can't be reliably compared without choosing to make some explicit assumptions, and I don't think Perl should make such choices for the programmer. That's why I want multiple comparison options, so that people have to explicitly choose what they want. How to do this, though, I'm unsure. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On Tue, Aug 18, 2009 at 15:20, Carl Mäsak wrote: > Leon (>): >> Reading this discussion, I'm getting the feeling that filename >> literals are increasingly getting magical, something that I don't >> think is a good development. The only sane way to deal with filenames >> is treating them as opaque binary strings, making any more assumptions >> is bound to get you into trouble. I don't want to deal with Windows' >> strange restrictions on characters when I'm working on Linux. I don't >> want to deal with any other platform's particularities either. >> Portability should be positive, not negative IMNSHO. The whole reason filenames/paths is a mess to code if because they are treated as binary strings in most cases. This is also why we have modules like File::Spec and bunch more on CPAN all trying to do the same thing. And today if I want to code something that works on all platforms I have to use that instead. How can this be positive? For me a Path literal is a way to get rid of all this bandage so we don't have to bother with the strange restrictions later when we get a bug report from a CPAN user. And there is nothing magical about it, no more so than if I ask for the length of UTF8 string I expect get back the number of characters not the number of bytes. A path is a well defined size on all platforms and should be treated as such. The main problems is that POSIX really never did cover this part too well. But today we have Unicode and UTF8 and as such this is the de facto default on most modern unix'es as most libraries and tools will write filenames in this format if so defined in the locale. Just writing binary data to a filename is bound to get you into trouble and you will quickly find that many of the common C libraries will fail if locale and filename does not match. So even on Linux/Unix a path really not just any number of bytes with / as delimiter. It depends on the locale and the encoding set for the file system and not caring about that will get you into trouble. But than again you always have the option of using p:unix{}, it's also a clear way to signal you really don't care about portability and that this will only work on Unix. Or you could even use Q{} as this pretty much will allow you to anything. >> >> As for comparing paths: reimplementing logic that belongs to the >> filesystem sounds like really Bad Idea™ to me. Two paths can't be >> reliably compared without choosing to make some explicit assumptions, >> and I don't think Perl should make such choices for the programmer. Getting any kind of path's from user input will require you to reimplement that logic if you care about validate data before throwing it at the file system. If you buy that paths are well defined types, then comparing paths should not require making any assumptions. We can compare Unicode string without making assumptions. > > Very nicely put. We can't predict the future, but in creating > something that'll at least persist through the next decade, let's not > do elaborate things with lots of moving parts. > > Let's make a solid ground to stand on; something so stable that it > works uphill and underwater. People with expertise and tuits will > write the facilitating modules. > > To quote Kernighan and Pike: Simplicity. Clarity. Generality. > I agree. > magic can always be added with module goodness > I completely agree we can't predict the future but we do have to make some sane choices about how the default should work, who knows if UTF8 will still be hot new thing in 10 years, but that's still the default assumption for much of Perl 6 if nothing else is known about the input we get. And I totally agree path literals should not be magically, they should be well defined and you should not suffer when using them because platform X or Y has strange restrictions. But when finding the sane default we have to make restrictions and POSIX's path is binary data, simply is to lax. My idea about using the lowest common denominator for modern Unix and windows was that we could get as much of Unicode in path names as possible without breaking on modern platforms and as a way to get Simplicity, Clarity and Generality into paths. Because this will never be simple, clear or general: File::Spec->catfile(qw(.. ext Sys Syslog macros.all)); or any of the other example that we can find: http://www.google.com/codesearch?hl=en&start=10&sa=N&q=FIle::Spec-%3Ecatfile Regards Troels
Re: Filename literals
Leon Timmermans wrote: Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. [...]. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. I'd like to agree, and also suggest that the use-case for filename literals probably favors the native approach. Most applications should not hard-code filename constants: they should use config files, ask users, or programatically construct them from other information. OTOH, one-liners and throw-away scripts will frequently hard code these things. So the filename literal syntax should optimize for this usage: a 90% solution that makes easy things trivial (but requires hard things to use an IO CTOR) seems to me to be what I'd want for a one-liner.
Re: Filename literals
On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: Some ways in which different paths can be considered equivalent: Spelling: ... Simplification: ... Resolution: ... Content-wise: ... Ok, my next commit will have "canonpath" (stolen directly from p5's File::Spec documentation), which will do "No physical check on the filesystem, but a logical cleanup of a path", and "realpath" (idea taken from p5's Cwd documentation), which will resolve symlinks, etc, and provide an absolute path. Oh, and "resolvepath", which does both. I'm not quite sure I followed all your discussion above -- have I left something out? I think there's a difference between "canonical" as in a webpage with , and "cleanup" as in Windows turning PROGRA~1 into "Program Files". There could also be other types of normalisation depending on the FS, but we probably shouldn't concern ourselves with them, other than having some way to get to such native calls. Anyway, my assumption is that there should be a number of comparison options. Since we do Str, we should get string comparison for free. But I'm expecting other options at other levels, but have no idea how or what at this point. As Leon Timmermans keeps reminding us, that really should be delegated to the OS/FS. I think $file1 =:= $file2 should ask the OS whether it thinks those are the same item or not (it can check paths, it can check inodes, whatever is its official way to compare file-thingies). Similarly, $file1.name === $file2.name should ask the OS whether it thinks those names mean the same thing. And if you want to compare the canonical paths or anything else, just say $file1.name.canonical === $file2.name.canonical, or use 'eq', or whatever you want to do, just do it explicitly. According to my last commit, p{} will return a Path object that just stores the path, but has methods attached for accessing all the metadata. But it doesn't do file opening or things like that (unless you use the :T and :B thingies, which read the first block and try to guess whether it's text or binary -- these are in Perl 5 too). There are two things going on here: the user-friendly syntax for casual use, which we basically agree should be something short and pithy, although we have but begun to shed this bike, I'm sure. $file = io "/foo/bar"; $file = p{/foo/bar}; $file = Q:p/foo/bar/; $file = File("/foo/bar"); However we end up spelling it, we want that to give us unified access to the separate inside parts: IO::Data# contents of file IO::Handle # filehandle for using manually IO::Metadata IO::Path I'm not sure why Path isn't actually just part of IO::Metadata... maybe it's just handy to have it out on its own because pathnames are so prominent. In any case, $file.size would just be shorthand for something like $file.io.metadata{size}. The :T and :B tests probably ought to be part of IO::Data, since they require opening the file to look at it; I'd rather put them there (vs. ::Metadata, which is all "outside" info) since plain ol' $file abstracts over that detail anyway. You can say $file.r, $file.x, $file.T, $file.B, and not care where those test live under the hood. We might actually want to distinguish IO::Metadata::Stat from IO::Metadata::Xattr or something... but that's probably too FS- specific. I don't think I mind much whether it's IO::Path or IO::Metadata::Path, or whether they both as exist as synonyms I think we want many of the same things, I'm just expressing them slightly differently. Let's keep working on this, and hopefully we end up with something great. Yes. A great mess! Er, wait, no And there's no perfect solution, but it would be useful for Perl to stick as closely as the FS/OS's idea of types as it can. Sometimes that would mean looking up an extension; it might mean using (or emulating) "file" magic; it might mean querying the FS for a MIME- type or a UTI. After all, the filename extension may not actually match the correct type of the file. My suggestion would be that it's an interesting idea, but should maybe be left to a module, since it's not a small problem. Of course, I'm happy to be overruled by a higher power :). I'd like the feature, I'm just unsure it deserved core status. Well, it's all modules anyway... certainly we'll have to rely on IO::Filesystem::XXX, but I do think this is another area to defer to the OS's own type-determining functions rather than try to do it all internally. What we should have, though, is a standard way to represent the types in Perl so that users know how to deal with them. I think roles are the obvious choice: if the OS tells you that a file is HTML, then $file would do IO::Datatype::HTML, which means in turn it would also do IO::Datatype::Plaintext, and so on. Of co
Re: Filename literals
I don't think $file1.name == $file2.name should talk to the FS, because I think File#name t+r whatever) should return a plain Str. Having magical FilePathName objects is handy, but sometimes you want to get the filename as a dumb string to do stringish things without having to worry about the fact that the string started life as the name of a file somewhere. I could convert it explicitly, but it's not obvious that I need to; 'name' sounds like something that should return Str. On 8/19/09, David Green wrote: > On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote: >> On Tue, 18 Aug 2009, David Green wrote: >>> Some ways in which different paths can be considered equivalent: >>> Spelling: ... Simplification: ... Resolution: ... Content-wise: ... >> Ok, my next commit will have "canonpath" (stolen directly from p5's >> File::Spec documentation), which will do "No physical check on the >> filesystem, but a logical cleanup of a path", and "realpath" (idea >> taken from p5's Cwd documentation), which will resolve symlinks, >> etc, and provide an absolute path. Oh, and "resolvepath", which >> does both. I'm not quite sure I followed all your discussion above >> -- have I left something out? > > I think there's a difference between "canonical" as in a webpage with > , and "cleanup" as in Windows turning PROGRA~1 > into "Program Files". There could also be other types of > normalisation depending on the FS, but we probably shouldn't concern > ourselves with them, other than having some way to get to such native > calls. > >> Anyway, my assumption is that there should be a number of >> comparison options. Since we do Str, we should get string >> comparison for free. But I'm expecting other options at other >> levels, but have no idea how or what at this point. > > As Leon Timmermans keeps reminding us, that really should be delegated > to the OS/FS. I think $file1 =:= $file2 should ask the OS whether it > thinks those are the same item or not (it can check paths, it can > check inodes, whatever is its official way to compare file-thingies). > Similarly, $file1.name === $file2.name should ask the OS whether it > thinks those names mean the same thing. And if you want to compare > the canonical paths or anything else, just say $file1.name.canonical > === $file2.name.canonical, or use 'eq', or whatever you want to do, > just do it explicitly. > >> According to my last commit, p{} will return a Path object that >> just stores the path, but has methods attached for accessing all the >> metadata. But it doesn't do file opening or things like that >> (unless you use the :T and :B thingies, which read the first block >> and try to guess whether it's text or binary -- these are in Perl 5 >> too). > > There are two things going on here: the user-friendly syntax for > casual use, which we basically agree should be something short and > pithy, although we have but begun to shed this bike, I'm sure. > > $file = io "/foo/bar"; > $file = p{/foo/bar}; > $file = Q:p/foo/bar/; > $file = File("/foo/bar"); > > However we end up spelling it, we want that to give us unified access > to the separate inside parts: > > IO::Data# contents of file > IO::Handle # filehandle for using manually > IO::Metadata > IO::Path > > I'm not sure why Path isn't actually just part of IO::Metadata... > maybe it's just handy to have it out on its own because pathnames are > so prominent. In any case, $file.size would just be shorthand for > something like $file.io.metadata{size}. The :T and :B tests probably > ought to be part of IO::Data, since they require opening the file to > look at it; I'd rather put them there (vs. ::Metadata, which is all > "outside" info) since plain ol' $file abstracts over that detail > anyway. You can say $file.r, $file.x, $file.T, $file.B, and not care > where those test live under the hood. > > We might actually want to distinguish IO::Metadata::Stat from > IO::Metadata::Xattr or something... but that's probably too FS- > specific. I don't think I mind much whether it's IO::Path or > IO::Metadata::Path, or whether they both as exist as synonyms > >> I think we want many of the same things, I'm just expressing them >> slightly differently. Let's keep working on this, and hopefully we >> end up with something great. > > Yes. A great mess! Er, wait, no > >>> And there's no perfect solution, but it would be useful for Perl to >>> stick as closely as the FS/OS's idea of types as it can. Sometimes >>> that would mean looking up an extension; it might mean using (or >>> emulating) "file" magic; it might mean querying the FS for a MIME- >>> type or a UTI. After all, the filename extension may not actually >>> match the correct type of the file. >> >> My suggestion would be that it's an interesting idea, but should >> maybe be left to a module, since it's not a small problem. Of >> course, I'm happy to be overruled by
Re: Filename literals
On Wed, 19 Aug 2009, Mark J. Reed wrote: I don't think $file1.name == $file2.name should talk to the FS, because I think File#name t+r whatever) should return a plain Str. Having magical FilePathName objects is handy, but sometimes you want to get the filename as a dumb string to do stringish things without having to worry about the fact that the string started life as the name of a file somewhere. I could convert it explicitly, but it's not obvious that I need to; 'name' sounds like something that should return Str. $file1.name == $file2.name is kinda strange because it does a numeric comparison between the filenames (see S03). Methinks you want $file1 eq $file2 (both of which are assumed to be of type Path) which does a string comparison between them without consulting the filesystem. Having said that, you've made me realise that $file1 == $file2 might be the perfect operator for comparing inodes, since inodes are numbers. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
I should've mentioned, though, we're currently using the smartmatch operator for this, so I'm thinking maybe I'll just stick with that. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Filename literals
On 2009-Aug-19, at 4:38 pm, Mark J. Reed wrote: I don't think $file1.name == $file2.name should talk to the FS, because I think File#name t+r whatever) should return a plain Str. I was thinking === rather than eq might be enough distinction, but you're right, confusion is too likely. Maybe $file1.name ~~ $file2.name? IO::Filesystem::compare- paths($file1, $file2) seems a tad wordy. On 2009-Aug-19, at 7:06 pm, Timothy S. Nelson wrote: Having said that, you've made me realise that $file1 == $file2 might be the perfect operator for comparing inodes, since inodes are numbers. Isn't that a bit FS-specific? Since inodes are less commonly used, I wouldn't mind making their use more explicit: $f1.inode == $f1.inode. Or to be less FS-specific, $f1.id == $f2.id? Where .id could return an inode, an FSspec, whatever is suitable to that filesystem. I should've mentioned, though, we're currently using the smartmatch operator for this, so I'm thinking maybe I'll just stick with that. Or $f1.id ~~ $f2.id, since whatever identifier the FS uses might not be numeric, yes. -David