Re: Filename literals

2009-08-19 Thread David Green
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 $

Re: Filename literals

2009-08-19 Thread Timothy S. Nelson
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-ma

Re: Filename literals

2009-08-19 Thread Timothy S. Nelson
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 t

Re: Filename literals

2009-08-19 Thread Mark J. Reed
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

Re: Filename literals

2009-08-19 Thread David Green
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

Re: Filename literals

2009-08-18 Thread Dave Whipp
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

Re: Filename literals

2009-08-18 Thread Troels Liebe Bentsen
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 filen

Re: Filename literals

2009-08-18 Thread Timothy S. Nelson
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 strin

Re: Filename literals

2009-08-18 Thread Daniel Carrera
+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.

Re: Filename literals

2009-08-18 Thread Jan Ingvoldstad
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

Re: Filename literals

2009-08-18 Thread Carl Mäsak
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 mo

Re: Filename literals

2009-08-18 Thread Timothy S. Nelson
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 di

Re: Filename literals

2009-08-18 Thread Leon Timmermans
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 ge

Re: Filename literals

2009-08-18 Thread David Green
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

Re: Filename literals

2009-08-18 Thread Timothy S. Nelson
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 c

Re: Filename literals

2009-08-18 Thread Troels Liebe Bentsen
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 re

Re: Filename literals

2009-08-17 Thread Timothy S. Nelson
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

Re: Filename literals

2009-08-17 Thread Jon Lang
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 wo

Re: Filename literals

2009-08-17 Thread Troels Liebe Bentsen
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 w

Re: Filename literals

2009-08-17 Thread Jon Lang
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

Re: Filename literals

2009-08-16 Thread Timothy S. Nelson
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,

Re: Filename literals

2009-08-16 Thread David Green
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 c

Re: Filename literals

2009-08-15 Thread Jon Lang
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 file

Re: Filename literals

2009-08-15 Thread Timothy S. Nelson
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 str

Re: Filename literals

2009-08-15 Thread Austin Hastings
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

Re: Filename literals

2009-08-15 Thread Timothy S. Nelson
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 ba

Re: Filename literals

2009-08-15 Thread Timothy S. Nelson
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,

Re: Filename literals

2009-08-14 Thread Jan Ingvoldstad
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

Re: Filename literals

2009-08-14 Thread Leon Timmermans
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

Re: Filename literals

2009-08-14 Thread Brandon S. Allbery KF8NH
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 driv

Re: Filename literals

2009-08-14 Thread Mark J. Reed
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

Re: Filename literals

2009-08-14 Thread Darren Duncan
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

Re: Filename literals

2009-08-14 Thread David Green
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 constr

Re: Filename literals

2009-08-14 Thread Timothy S. Nelson
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::F

Re: Filename literals

2009-08-14 Thread Timothy S. Nelson
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 :).

Re: Filename literals

2009-08-14 Thread Leon Timmermans
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, parsin

Re: Filename literals

2009-08-14 Thread Richard Hainsworth
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 equi

Re: Filename literals

2009-08-14 Thread David Green
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

Re: Filename literals

2009-08-14 Thread Timothy S. Nelson
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 (

Re: Filename literals

2009-08-13 Thread Darren Duncan
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. Tha

Filename literals

2009-08-13 Thread Hinrik Örn Sigurðsson
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 the