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-
r27999 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-08-15 13:19:43 +0200 (Sat, 15 Aug 2009)
New Revision: 27999
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S02,S16,S32/IO] Added special quoting that creates IO::FSNode objects.
This could still be controversial, but I've gone with the
Forgiveness/Permission thing. If no-one fights it, I'll revise the
Draft IO specs (S16 and S32/IO) to refer to IO::FSNode objects in
appropriate places instead of strings.
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-15 05:51:50 UTC (rev 27998)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-15 11:19:43 UTC (rev 27999)
@@ -2834,6 +2834,7 @@
:subst Parse as substitution
:trans Parse as transliteration
:code Quasiquoting
+:io Return an IO::FSNode
You may omit the first colon by joining an initial CQ, Cq, or Cqq with
a single short form adverb, which produces forms like:
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-15 05:51:50 UTC (rev 27998)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-15 11:19:43 UTC (rev 27999)
@@ -78,6 +78,21 @@
S32-setting-library/IO.pod. The main functions used are listed in S29 with
references to
S32-setting-library/IO.pod.
+=head2 Special Quoting Syntax
+
+The use of filenames requires a special quoting syntax. It works as follows:
+
+q:io{/path/to/file}
+
+The quote characters can be any of the usual ones, although / is probably a
bad choice
+for filenames.
+
+The code shown above returns an IO::FSNode object (or a descendant thereof).
+
+Naturally you can also ask for interpolation in filenames:
+
+qq:io{$directory/$file}
+
=head1 Name Services
=head2 User role
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-15 05:51:50 UTC (rev
27998)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-15 11:19:43 UTC (rev
27999)
@@ -587,19 +587,18 @@
:$Readable
);
-The CFSNode, CFilename and Cfd options are mutually exclusive. If
Cuse portable is in
-effect, the CFilename option throws an error; use an CFSNode instead.
+The CFSNode and Cfd options are mutually exclusive.
CNoOpen is passed to CIO::Streamable.new()
Examples:
-# Read -- throws errors with 'use portable'
-$fobj = new IO::File(Filename = $filename);
+# Read, no interpolation
+$fobj = new IO::File(FSNode = q:io{/path/to/file});
-# Write -- works with 'use portable'
+# Write, interpolation
$fobj = new IO::File(
-FSNode = IO::FSNode.new(type = 'Unix', Filename = $filename),
+FSNode = q:io:qq{$filename},
Writeable = 1
);
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. Nelsonwayl...@wayland.id.au 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) {
say Readable;
}
Anyway, we have possibilities. Further thoughts anyone?
As illustrated above, I think
