What should file test operators return?
At the moment the file test operators that I expect to return true or
false do, but the true is the filename. I expected a boolean, for no
other reason than Perl 6 has them so it might as well use them. The
section on Smart Matching in S03 says that the ~~ doesn't have to
return a boolean, but aside from things liek :s, :M, and :A, what good
would it be not to? I'm happy to update S16 with whatever the answer
is. :)
Here's my code example that motivates this question. For a Llama6
exercise with file test operators, I wanted to create a little table:
for @files - $file {
printf %-70s %s %s %s\n,
$file,
$file ~~ :r,
$file ~~ :w,
$file ~~ :x;
}
I get the filename for each part:
foo foo foo
Which I wanted to work like this perl5 (not that I care if it's
different, I just have to explain it to reader)
#!/usr/bin/perl5
foreach ( glob( * ) )
{
printf %30s %s %s %s\n, $_, -r, -w, -x
}
With the Pugs 6.2.13 (r15868), only the ~~ form seems to work, but is
that going to be any different than the other two forms?
pugs ( Talks ~~ :r ).say
Talks
Bool::True
pugs ( Talks ~~ :d ).say
Talks
Bool::True
pugs Talks.TEST(:s).say
*** No such method in class Str: TEST
at interactive line 1, column 1-21
pugs Talks.:s
Internal error while running expression:
***
Unexpected :s
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9
pugs Talks.:d
Internal error while running expression:
***
Unexpected \:
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9
Re: What should file test operators return?
Hi, brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. If you want a boolean, use ? $fn ~~ :x or something. HTH, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ - http://sudokugarden.de/ - http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: What should file test operators return?
On 13/04/07, Moritz Lenz [EMAIL PROTECTED] wrote:
If you want a boolean, use
? $fn ~~ :x
or something.
Definitely or something. Unary ? has the wrong precedence there.
You could write:
for @files - $file {
printf %-70s %s %s %s\n,
$file,
true $file ~~ :r,
true $file ~~ :w,
true $file ~~ :x;
}
which could, of course be hyperoperated:
for @files - $file {
printf %-70s %s %s %s\n,
$file,
true $file ~~ (:r, :w, :x);
}
Maybe there also needs to be a boolean conversion for printf
(perhaps %t for true?):
for @files - $file {
printf %-70s %t %t %t\n,
$file,
$file ~~ :r,
$file ~~ :w,
$file ~~ :x;
}
Which leads to:
for @files - $file {
printf %-70s %t %t %t\n,
$file,
$file ~~ (:r, :w, :x);
}
Damian
Re: What should file test operators return?
Damian Conway skribis 2007-04-13 20:01 (+1000): Maybe there also needs to be a boolean conversion for printf (perhaps %t for true?): I often use [ ] and [X] to represent true and false in text output. They resemble checkboxes. I don't think printf needs a boolean output template, but it would be nice if it were configurable. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Does =$*ARGS work?
on 4/11/2007 10:29 AM brian d foy said the following: The $*ARGS variable shows up in this file, which looks like it's still maintained: http://svn.pugscode.org/pugs/docs/AES/S28draft.pod That's a typo (mine). It should be @*ARGS and refers to simple access to the command line arguments. (Fixed.) dvergin
Re: Synopsis 26
Version 0.0.3 of the Perl6::Perldoc suite is now on CPAN. I've ripped out the previous, extremely brittle, test suite and replaced it with a much larger one whose tests are fully abstracted, declarative, and OO (and hence may be useful to other Perl 6 implementors as well). The new tests don't require any YAML support either. Special thanks to Ævar Arnfjörð Bjarmason for thoroughly investigating the previous problems with the test suite, and to Matthew Wilson for SVNing the previous version and offering to tackle the testing problems. Damian
Re: What should file test operators return?
On Fri, Apr 13, 2007 at 10:29:43AM +0100, Moritz Lenz wrote: Hi, brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. If you want a boolean, use ? $fn ~~ :x or something. It might also be useful when the test is being applied to a junction - it gives the effect of grep. --
Re: What should file test operators return?
On Apr 12, 2007, at 14:52 , brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. I expected a boolean, for no other reason than Perl 6 has them so it might as well use them. This is documented somewhere already. Pugs does not implement the spec as documented, though. File tests are supposed to return something which: - behaves as a Bool - stringifies as a filename - numifies as a file size or as a time, if appropriate - propagates a stat object (obviating perl5's magic _) Current Pugs only does the first three, sort of: the size and time operators return numeric, the others string, all behave appropriately if used as booleans. This means you mostly get the expected results for chained tests, at the price of every operator doing its own stat(). My impression is that junction types aren't really there yet, so this is the best that can currently be done. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH
Re: Does =$*ARGS work?
In article [EMAIL PROTECTED], David Vergin [EMAIL PROTECTED] wrote: on 4/11/2007 10:29 AM brian d foy said the following: The $*ARGS variable shows up in this file, which looks like it's still maintained: http://svn.pugscode.org/pugs/docs/AES/S28draft.pod That's a typo (mine). It should be @*ARGS and refers to simple access to the command line arguments. (Fixed.) Shouldn't $*ARGS still show up as the P6 counterpart to ARGV? S*ARGS as the filehandle shows up in S04.
Re: What should file test operators return?
In article [EMAIL PROTECTED], Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Apr 12, 2007, at 14:52 , brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. I expected a boolean, for no other reason than Perl 6 has them so it might as well use them. This is documented somewhere already. Pugs does not implement the spec as documented, though. That's part of the problem: finding that somewhere, then makign the other somewhere's agree with it.
Re: What should file test operators return?
In article [EMAIL PROTECTED], Moritz Lenz [EMAIL PROTECTED] wrote: brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. That's fine, but the example in S16 shows that as a junction: $fh ~~ :t :x I don't mind the answer being whatever it is as long as it's really the answer that I can tell newbies and point to in the docs. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: File tests are supposed to return something which: - behaves as a Bool - stringifies as a filename - numifies as a file size or as a time, if appropriate - propagates a stat object (obviating perl5's magic _) Current Pugs only does the first three, sort of: the size and time operators return numeric, the others string, all behave appropriately if used as booleans. I'm not sure Pugs does that right. The file named 0 (zero) seems to behave inappropriately. In this example, foo and 0 are real files, and not there is not a file that exists: pugs foo ~~ :e foo pugs true foo ~~ :e Bool::True pugs not there ~~ :e Bool::False pugs true not there ~~ :e Bool::False pugs 0 ~~ :e 0 pugs true 0 ~~ :e Bool::False Again, I don't really mind whatever the answer is as long as I can document it. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Moritz Lenz [EMAIL PROTECTED] wrote: Hi, brian d foy wrote: At the moment the file test operators that I expect to return true or false do, but the true is the filename. that helps chaining of file test: $fn ~~ :t ~~ :x or something. I thought that returning a stat buffer was supposed to handle the case of chained file test operators. S16 will also need a fix-up for this text, I think: Also note that, for the superuser on the local filesystems, the :r, :R, :w, and :W tests always return 1,
Re: What should file test operators return?
On Apr 13, 2007, at 9:04 , brian d foy wrote: In article [EMAIL PROTECTED], Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: File tests are supposed to return something which: - behaves as a Bool - stringifies as a filename - numifies as a file size or as a time, if appropriate - propagates a stat object (obviating perl5's magic _) Current Pugs only does the first three, sort of: the size and time operators return numeric, the others string, all behave appropriately if used as booleans. I'm not sure Pugs does that right. The file named 0 (zero) seems to I'm not surprised; as I said, the current behavior is basically a placeholder. In the final implementation the real value will be the stat structure, which won't have the 0 vs. '0' ambiguity. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH
Re: Does =$*ARGS work?
on 4/13/2007 4:55 AM brian d foy said the following: Shouldn't $*ARGS still show up as the P6 counterpart to ARGV? S*ARGS as the filehandle shows up in S04. Yup. Fixed now in S28draft.pod. Mention in Variable.pod will follow. dvergin
[svn:perl6-synopsis] r14372 - doc/trunk/design/syn
Author: larry
Date: Fri Apr 13 10:02:01 2007
New Revision: 14372
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarification of simplified return values of filetests for brian.d.foy++.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podFri Apr 13 10:02:01 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 16 Mar 2007
+ Last Modified: 13 Apr 2007
Number: 3
- Version: 110
+ Version: 111
=head1 Overview
@@ -1477,30 +1477,36 @@
=item *
-The filetest operators are gone. We now use a Pair as either a
+The filetest operators are gone. We now use a CPair as either a
pattern or a method name to get the same effect:
if $filename ~~ :e { say exists }
if $filename.:e { say exists }
-Both of these forms actually translate to
-
-if $filename.STATUS(:e) { say exists }
-
-which is a generic mechanism that dispatches to the object's
-class to find the definition of CSTATUS. (It just happens that CStr
-(filenames) and CIO (filehandles) default to the expected filetest
-semantics, but C$regex.:i might tell you whether the regex is case
-insensitive, for instance.)
+The 1st form actually translates to the latter form, so the object's
+class decides how to dispatch pair methods. It just happens that
+CStr (filenames), CIO (filehandles), and CStatbuf (stat buffers)
+default to the expected filetest semantics, but C$regex.:i might
+tell you whether the regex is case insensitive, for instance.
Using the pattern form, multiple tests may be combined via junctions:
given $handle {
-when all :r :w :x {...}
+when :r :w :x {...}
when :!w | :!x{...}
when *{...}
}
+When adverbial pairs are stacked into one term, it is assumed they are
+ANDed together, so
+
+when :r :w :x
+
+is equivalent to either of:
+
+when :r :w :x
+when all(:r,:w,:x)
+
The advantage of the method form is that it can be used in places that
require tighter precedence than C~~ provides:
@@ -1510,13 +1516,23 @@
sort { .:M }, @files
-But that demonstrates the other advantage of the method form.
+But that demonstrates the other advantage of the method form, which is
+that it allows the unary dot syntax to test the current topic.
+
+Unlike in earlier versions of Perl 6, these filetests do not return
+stat buffers, but simple scalars of type CBool, CInt, or CNum.
-In general, the user need not worry about caching the stat buffer.
-The stat buffer will automatically be reused if the same object has
-recently been queried, where recently is defined as less than a
-second or so. If this is a concern, an explicit stat() or lstat()
-on that file will automatically reset the stat buffer for that file.
+In general, the user need not worry about caching the stat buffer
+when a filename is queried. The stat buffer will automatically be
+reused if the same object has recently been queried, where recently
+is defined as less than a second or so. If this is a concern, an
+explicit stat() or lstat() may be used to return an explicit stat
+buffer object that will not be subject to timeout, and may be tested
+repeatedly just as a filename or handle can. A CStatbuf object has
+a C.file method that can be queried for its filename (if known);
+the C.io method returns the handle (if known). If the CStatbuf
+object doesn't know its filename but does know its IO handle, then
+C.file attempts to return C.io.file.
Note that C:s still returns the filesize, but C:!s is true
only if the file is of size 0.
Re: What should file test operators return?
On Fri, Apr 13, 2007 at 08:01:13PM +1000, Damian Conway wrote: : Maybe there also needs to be a boolean conversion for printf : (perhaps %t for true?): Seems insufficiently general. However, I note that booleans are an enum, and by default stringify to Bool::True or Bool::False. Maybe %t stands for terse, which stringifies to True and False, and in general stringifies any enum to its unqualified name rather than its qualified name. Kind of a shame %e is taken. On the other hand, maybe wasting a printf char on this is still insufficiently general, and it should just be a .terse or .key method of some sort feeding to a normal %s. Larry
Re: What should file test operators return?
On Thu, Apr 12, 2007 at 01:52:50PM -0500, brian d foy wrote:
: At the moment the file test operators that I expect to return true or
: false do, but the true is the filename.
You've just dug up a pugsian fossil.
: I expected a boolean, for no
: other reason than Perl 6 has them so it might as well use them. The
: section on Smart Matching in S03 says that the ~~ doesn't have to
: return a boolean, but aside from things liek :s, :M, and :A, what good
: would it be not to? I'm happy to update S16 with whatever the answer
: is. :)
The intent of moving from the
-r -w -x $file
form to the
$file ~~ :r :w :x
form was to get rid of the klunky, inflexible statbuffer propagation
mechanism, which (without an temp var) could only do and and not
or, and didn't work well syntactically in when statements. Plus
it forced the user to worry about statbuf caching, which probably just
ought to timeout automatically since it assumes we're the only person
accessing the filesystem, a bogus assumption in the face of any kind
of multiprocessing.
So the new filetests just return a simple value, generally Bool or Num.
To get a statbuf object you now use an explicit stat or lstat. Such an
object should probably stringify to Stat('filename') or some such, so
that the filename 0 comes out Stat('0').
I will attempt to clarify S03, though my brain is still a little
fuzzy this week for a variety of unrelated reasons.
: Here's my code example that motivates this question. For a Llama6
: exercise with file test operators, I wanted to create a little table:
:
:for @files - $file {
: printf %-70s %s %s %s\n,
: $file,
: $file ~~ :r,
: $file ~~ :w,
: $file ~~ :x;
: }
I think I would now write that more like:
for @files - $file {
given stat $file {
printf %-70s %s %s %s\n, $file, .:r, .:w, .:x;
}
}
: Which I wanted to work like this perl5 (not that I care if it's
: different, I just have to explain it to reader)
:
:#!/usr/bin/perl5
:foreach ( glob( * ) )
: {
: printf %30s %s %s %s\n, $_, -r, -w, -x
: }
:
:
: With the Pugs 6.2.13 (r15868), only the ~~ form seems to work, but is
: that going to be any different than the other two forms?
The current pugs implementation is just translating to the old form
underneath, so it's not surprising it's a bit off. That's the sort
of thing that happens when the language designer gives the language
implementor whiplash. However, I rather suspect the interpersonal
metaphorical meaning was lost on the physicist/comic who decided that
the 3rd derivative of position should be called jerk. :)
Larry
Re: What should file test operators return?
In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:
On Thu, Apr 12, 2007 at 01:52:50PM -0500, brian d foy wrote:
: Here's my code example that motivates this question. For a Llama6
: exercise with file test operators, I wanted to create a little table:
:
:for @files - $file {
: printf %-70s %s %s %s\n,
: $file,
I think I would now write that more like:
for @files - $file {
given stat $file {
printf %-70s %s %s %s\n, $file, .:r, .:w, .:x;
}
}
Hmmm, that's a good little bit of code, as was Damian's use of the
hyper-operator. The trick is to figure how how much I can use in Llama
6 without scaring off the reader. :)
I'm actually starting at the back of the book so I know what I have to
put in the front of the book to get that far. In previous Llamas the
file tests operators came before stat, but maybe this answer is a good
end-of-chapter sorta thing.
I'll also have to think about using given {} merely as a topicalizer
too, I guess, although showing it next to an explicit assignment to $_.
:)
Re: What should file test operators return?
I think I need to reread the docs. What's the colon in the method calls for?
(That is, why is it $stat_obj.:r instead of just $stat_obj.r ?)
On 4/13/07, brian d foy [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:
On Thu, Apr 12, 2007 at 01:52:50PM -0500, brian d foy wrote:
: Here's my code example that motivates this question. For a Llama6
: exercise with file test operators, I wanted to create a little table:
:
:for @files - $file {
: printf %-70s %s %s %s\n,
: $file,
I think I would now write that more like:
for @files - $file {
given stat $file {
printf %-70s %s %s %s\n, $file, .:r, .:w, .:x;
}
}
Hmmm, that's a good little bit of code, as was Damian's use of the
hyper-operator. The trick is to figure how how much I can use in Llama
6 without scaring off the reader. :)
I'm actually starting at the back of the book so I know what I have to
put in the front of the book to get that far. In previous Llamas the
file tests operators came before stat, but maybe this answer is a good
end-of-chapter sorta thing.
I'll also have to think about using given {} merely as a topicalizer
too, I guess, although showing it next to an explicit assignment to $_.
:)
--
Mark J. Reed [EMAIL PROTECTED]
File test operators as Pairs
So far (eep!), the documentation talks about file test operators as working with pairs, which will be a weird thing to explain, I guess. I'm wondering if this matters to the mere user at all, and if we should even talk about them in terms of pairs. I don't want a different set of terms in the docs and Llama6. Even if the current Pugs is different than what the final answer will be, as long as I know the final answer I'll be fine. :) For a directory that exists, using the adverbial form or the fat arrow form work for true or false things: pugs 'doc' ~~ :d doc pugs doc ~~ d = 1 doc pugs doc ~~ d = 0 Bool::False The fat arrow doesn't seem to work as I expected with :s though. I figured that the value of the pair would be the thing to match the answer of the test. I expect these all to be expressions of the same goal (even if they return different things right now): pugs doc ~~ :s # just to show you where I am 136 pugs ( doc ~~ :s ) == 136 Bool::True pugs ( doc ~~ :s ) ~~ 136 Bool::True pugs doc ~~ s = 136 # perhaps accidentally fine 136 So, if I wanted to see if the file had a size of 93 bytes, I'd use 93 as the value of the pair, but that doesn't work. It just returns true again: pugs doc ~~ s = 93 # I want this to fail (return Bool:I:False) 136 Similarly, if that last form should work, I might want to do something similar with the file age tests. I want a file 5 days old (let's ignore fractional days right now): doc ~~ M = 5; Which then makes me think I'd want to do something a bit wacky to see if the modtime is greater than 5: doc ~~ M = any( 5 ..* ); But, if file tests aren't really meant to be like this and the user shouldn't ever think like this, do I call it a pair? That's the question I'll have to answer to the newbie reading LLama6, even though I personally am fine with the term. :)
Re: What should file test operators return?
In article [EMAIL PROTECTED], Mark J. Reed [EMAIL PROTECTED] wrote: I think I need to reread the docs. What's the colon in the method calls for? (That is, why is it $stat_obj.:r instead of just $stat_obj.r ?) I can't answer the why question, but the stuff in S02 might help you. Look for generalized adverbial form: http://feather.perl6.nl/syn/S02.html The file test is really an adverbial pair (and see the message about pairs that I just posted). Larry just updated S03 with some clarification on file tests. Look at the section on Changes to Perl 5 Operators http://feather.perl6.nl/syn/S03.html
Re: File test operators as Pairs
On 4/13/07, brian d foy [EMAIL PROTECTED] wrote: Which then makes me think I'd want to do something a bit wacky to see if the modtime is greater than 5: doc ~~ M = any( 5 ..* ); Or even doc ~~ M = (5..*). Then again, (doc ~~ :M) ~~ 5..* does the same thing, without having to have pattern matching in two different places. It seems like the pairness of the pair is pretty useless in this case; i.e. it's a hack to fudge Lisp- or Ruby-style symbols. But symbols would be a hack in this case, too. These things are methods, and I'm not sure why we've crammed them into smart match. Things like :M have nothing to do with matching. What would it mean if smart match returned false? This file has not been modified ever? :e has a bit more merit for a smart match, but the operation has little to do with the concept of a string or the pair e = 1. I'm inclined to say that the best solution for filetests is to throw out our dwimmery altogether. Back in Perl 4 days, using stat explicitly was awkward, because you had to use it as a list and memorize the positions of all the returns. -s $file beats the heck out of (stat $file)[7], for sure. It also had the benefit that shell people would instantly recognize what's going on. However, now we have stat($file).size. With that, every programmer will recognize what's going on, not just people with shell background. And I don't think even people with a shell background will know what ($file ~~ :s) means (their guess could be right, but they'd have to look it up to confirm, and they would never think to *write* such a thing). I can never remember whether mtime is -m or -M anyway... Let's get rid of all the filetest magic, in favor of using stat explicitly. Luke
[svn:perl6-synopsis] r14373 - doc/trunk/design/syn
Author: larry Date: Fri Apr 13 16:23:17 2007 New Revision: 14373 Modified: doc/trunk/design/syn/S03.pod Log: Ranges over enums and such also can use *, suggested by Jonathan Lang++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podFri Apr 13 16:23:17 2007 @@ -14,7 +14,7 @@ Date: 8 Mar 2004 Last Modified: 13 Apr 2007 Number: 3 - Version: 111 + Version: 112 =head1 Overview @@ -749,7 +749,7 @@ These operators compare their operands using numeric, string, or Ceqv semantics respectively, and depending on the order return one of COrder::Increase, COrder::Same, or COrder::Decrease -(which numerify to -1, 0, or +1). See L/Comparion semantics. +(which numerify to -1, 0, or +1). See L/Comparison semantics. =item * @@ -2104,18 +2104,20 @@ 2.1 ~~ 1..2# false, equivalent to 1 = 2.1 = 2 If a C* (see the Whatever type in S02) occurs on the right side -of a range, it is taken to mean positive infinity in whatever space -the range is operating. A C* on the left means negative infinity -for types that support negative values. (The sign of those infinities -reverses for a negative step.) If the C* occurs on one side but -not the other, the type is inferred from the other argument. A star -on both sides will match any value that supports the COrdered role. +of a range, it is taken to mean positive infinity in whatever +typespace the range is operating, as inferred from the left operand. +A C* on the left means negative infinity for types that support +negative values, and the first value in the typespace otherwise as +inferred from the right operand. (For signed infinities the signs +reverse for a negative step.) A star on both sides prevents any type +from being inferred other than the COrdered role. 0..*# 0 .. +Inf 'a'..* # 'a' .. 'z...' *..0# -Inf .. 0 *..*# -Inf .. +Inf, really Ordered 1.2.3..*# Any version higher than 1.2.3. +May..* # May through December Note: infinite lists are constructed lazily. And even though C*..* can't be constructed at all, it's still useful as a selector object.
Re: [S03] Negation metaoperator
On Thu, Apr 05, 2007 at 11:07:12PM -0700, Jonathan Lang wrote: : Generalize the negated relational operators to apply to any infix : operator that returns a boolean. In terms of the standard operators, : this will add || ^^ // and or xor err to the family that is : implicitly equipped with logical negations. This will not fly, I'm afraid. These relationals are not typed to return Bool, but rather Any. They work only because all normal values do the boolean and defined roles, and the operator happens to evaluate one or more of its Any values for its boolean or defined sense. But the return value is one or another of the Any values (apart from the XORs, which do at least return False unless only one of the Anys is true, in which case you still get an Any). So basically, either we'd have to pick and choose by precedence level which infix operators allow meta-!, or open it up to all infix. That could get a little strange: $a = $b !but $c; Though one odd operator that might actually be useful is $a = $b !% $c; # short for $a = $b % $c == 0 I doubt that would turn out to be a Best Practice though, and in general even negated logicals are not going to be terribly useful in reduce. So I'm not inclined to change anything currently. Larry
Re: File test operators as Pairs
Luke Palmer wrote:
These things are methods, and I'm not sure why we've crammed them into
smart match. Things like :M have nothing to do with matching. What
would it mean if smart match returned false? This file has not been
modified ever? :e has a bit more merit for a smart match, but the
operation has little to do with the concept of a string or the pair e
= 1.
Also, I found the following line from S03 to be jolting:
Any Pair test object .STATUS(X) (Str,IO do filetest)
It struck me as a rather specific application for such a generic data type.
I'm inclined to say that the best solution for filetests is to throw
out our dwimmery altogether. Back in Perl 4 days, using stat
explicitly was awkward, because you had to use it as a list and
memorize the positions of all the returns. -s $file beats the heck
out of (stat $file)[7], for sure. It also had the benefit that shell
people would instantly recognize what's going on.
However, now we have stat($file).size. With that, every programmer
will recognize what's going on, not just people with shell background.
And I don't think even people with a shell background will know what
($file ~~ :s) means (their guess could be right, but they'd have to
look it up to confirm, and they would never think to *write* such a
thing).
I can never remember whether mtime is -m or -M anyway...
Let's get rid of all the filetest magic, in favor of using stat explicitly.
I tend to agree that the magic should go away. However, I already
miss the filetest operators. Given the way that prefix operators
work, wasn't it already possible to say something like the following?
given $handle {
when .'-r' .'-w' .'-x' { ... }
when !.'-w' | !.'-x' { ... }
when * { ... }
}
sort { $^a.'-M' = $^b.'-M' }, @files
sort { .'-M' }, @files
What does pair notation buy us that quoted-postfix notation doesn't
already cover?
--
Jonathan Dataweaver Lang
Re: File test operators as Pairs
On Apr 13, 2007, at 20:09 , Jonathan Lang wrote: What does pair notation buy us that quoted-postfix notation doesn't already cover? I don't think it does. What it does buy is that the *unquoted* notation works: the definition of Perl6's grammar turns out to lead to `-f' and `- f' parsing identically because tokens must be composed of characters all from the same group (e.g. alphanumeric, or punctuation, etc.), which causes problems. Larry's fix was to switch to adverbial form, and modify the way they were used to fit the adverbial paradigm. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH
Re: File test operators as Pairs
In article [EMAIL PROTECTED], Luke Palmer [EMAIL PROTECTED] wrote: However, now we have stat($file).size. That's sorta fine with me. That makes it even easier to explain to newbies, although I'd need method names for the other tests. However, junctive tests are a mighty attractive feature and I'd hate to lose those, whatever the syntax.
[svn:perl6-synopsis] r14374 - doc/trunk/design/syn
Author: larry Date: Fri Apr 13 17:59:55 2007 New Revision: 14374 Modified: doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S12.pod Log: Eliminated STATUS in favor of normal dispatch to :foo pair-handling methods. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podFri Apr 13 17:59:55 2007 @@ -14,7 +14,7 @@ Date: 8 Mar 2004 Last Modified: 13 Apr 2007 Number: 3 - Version: 112 + Version: 113 =head1 Overview @@ -2266,7 +2266,7 @@ Any Num numeric equality+$_ == X Any Str string equality ~$_ eq X -Any Pair test object .STATUS(X) (Str,IO do filetest) +Any Pair test object .:Xkey(Xval) (e.g. filetests) Set Set identical sets $_ === X Hash Set hash keys same set $_.keys === X Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podFri Apr 13 17:59:55 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 27 Oct 2004 - Last Modified: 11 Mar 2007 + Last Modified: 13 Apr 2007 Number: 12 - Version: 45 + Version: 46 =head1 Overview @@ -613,26 +613,15 @@ =head1 Pair query methods Certain classes such as filehandles allow colon pairs to be used as if they -were methods. When you say: +were methods. Method names beginning with a colon: $filehandle.:e $filehandle.:!x -it actually calls - -$filehandle.STATUS(:e) -$filehandle.STATUS(:!x) - -which is expected to return a value that can be used as a boolean. +are expected to return a value that can be used as a boolean. While this is primarily intended for use by file tests, other classes -may define a CSTATUS method to provide a similar mechanism for interrogating -lightweight properties without having to define methods for all of them. - -Note, though, that Iall such queries are answered by the first located -CSTATUS method--they are not inherited independently. The CSTATUS method -must explicitly pass the query on to other classes in such cases. Likewise, -if conflicting CSTATUS methods are composed from two different roles, they -must be disambiguated as any other conflicting method would be. +may define such methods to provide a similar mechanism for interrogating +properties. Depending on the class, the pairs in question may have arguments. The CHash class in particular makes use of pair syntax for subscript @@ -643,7 +632,10 @@ This has the advantage that the pair's argument is actually parsed exactly as a subscript would be. A C.exists() method could not easily make -such a guarantee about its arguments. +such a guarantee about its arguments. Plus you can say: + +%hash.:existsfoo +%hash.:deletefoo Conjecture, the trailing subscript adverbs could be brought up front as well:
Re: Should a dirhandle be a filehandle-like iterator?
brian d foy wrote:
As I was playing around with dirhandles, I thought What if... (which
is actualy sorta fun to do in Pugs, where Perl 5 has everything
documented somewhere even if nobody has read it).
My goal is modest: explain fewer things in the Llama. If dirhandles
were like filehandles, there's a couple of pages of explanation I don't
need to go through.
Witness:
I can iterate through the elements of a named array with [EMAIL PROTECTED]:
my @a = 1 2 3 4 5 ;
for [EMAIL PROTECTED] { .say } # but not = 1 2 3 4 5 :(
and I can read lines from a file:
for =$fh { .say }
Should I be able to go through a directory handle that way too? A yes
answer would be very pleasing :)
my $dh = doc.opendir;
for =$dh { .say }# doesn't work in pugs
And, since we're using objects now, .closedir can really just be
.close, right?
Please. I've always found the opendir ... readdir ... closedir set
to be clunky.
Also: why distinguish between open and opendir? If the string is
the name of a file, 'open' means open the file; if it is the name of
a directory, 'open' means open the directory. If it's the name of a
pipe, it opens the pipe. And so on.
Note that the above could be further shorthanded, as long as you don't
need the directory handle after the loop:
for =doc.open { .say }
--
Jonathan Dataweaver Lang
Re: Should a dirhandle be a filehandle-like iterator?
On Fri, 2007-04-13 at 19:00 -0700, Jonathan Lang wrote: Please. I've always found the opendir ... readdir ... closedir set to be clunky. Also: why distinguish between open and opendir? If the string is the name of a file, 'open' means open the file; if it is the name of a directory, 'open' means open the directory. If it's the name of a pipe, it opens the pipe. And so on. As long as you still have some way to reach the low-level opens -- though it's an odd thing to do (except perhaps in a disk integrity checker), there's no fundamental reason why you shouldn't be able to actually look at the bytes that happen to represent a directory structure on disk. Also, for security or correctness reasons you may want to make sure that you don't clobber things you don't mean to -- so non-dwimmy open variants are a good idea to keep around. This could be as simple as 'open(:!dwim)' I guess, or whatever the negated boolean adverb syntax is these days -'f
Re: Should a dirhandle be a filehandle-like iterator?
Geoffrey Broadwell wrote: Jonathan Lang wrote: Also: why distinguish between open and opendir? If the string is the name of a file, 'open' means open the file; if it is the name of a directory, 'open' means open the directory. If it's the name of a pipe, it opens the pipe. And so on. As long as you still have some way to reach the low-level opens -- though it's an odd thing to do (except perhaps in a disk integrity checker), there's no fundamental reason why you shouldn't be able to actually look at the bytes that happen to represent a directory structure on disk. It wouldn't be hard to allow .openfile, .opendir, and .openpipe as well as .open. -- Jonathan Dataweaver Lang
Re: Should a dirhandle be a filehandle-like iterator?
JL == Jonathan Lang [EMAIL PROTECTED] writes: JL Please. I've always found the opendir ... readdir ... closedir set JL to be clunky. JL Also: why distinguish between open and opendir? If the string is JL the name of a file, 'open' means open the file; if it is the name of JL a directory, 'open' means open the directory. If it's the name of a JL pipe, it opens the pipe. And so on. maybe this won't help you but if you did open on a dir in perl5 you can read the raw directory data which is pretty useless in most cases. so with open working as opendir on directories, what is the op/method to get the next directory entry? that isn't the same as reading a line. there won't be any trailing newlines to chomp. marking a location is not the same with tell and telldir (one is a byte offset, the other a directory entry index). and since dirs can reorder their entries (especially hash based dirs) the ordering and seek points may move. not gonna happen on text files. there are many differences and the only one you seem to see is a linear scan of them (which is just the most common access style). the operations you can do on the handles are very different as well. you can't write to a dir. dirs have no random access (you can lookup by a name with open but you can't go to the nth entry). and on OS with extra stuff like version numbers, then all bets are off. yes, you can tell the dir is such by doing a stat and then open can dwim but i don't see the overlap as you do. dirs generally are ordered lists of strings and have many different underlying formats based on their file systems. mapping that to a text file of lines doesn't work for me. this may all be obvious stuff but i think it deserves mentioning. if dirs mapped well onto file handles they would have been mapped that way long ago in the OS. in 30+ years that hasn't happened afaik. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Should a dirhandle be a filehandle-like iterator?
Uri Guttman wrote: JL == Jonathan Lang [EMAIL PROTECTED] writes: JL Please. I've always found the opendir ... readdir ... closedir set JL to be clunky. JL Also: why distinguish between open and opendir? If the string is JL the name of a file, 'open' means open the file; if it is the name of JL a directory, 'open' means open the directory. If it's the name of a JL pipe, it opens the pipe. And so on. maybe this won't help you but if you did open on a dir in perl5 you can read the raw directory data which is pretty useless in most cases. so with open working as opendir on directories, what is the op/method to get the next directory entry? that isn't the same as reading a line. there won't be any trailing newlines to chomp. marking a location is not the same with tell and telldir (one is a byte offset, the other a directory entry index). and since dirs can reorder their entries (especially hash based dirs) the ordering and seek points may move. not gonna happen on text files. there are many differences and the only one you seem to see is a linear scan of them (which is just the most common access style). Well, I did suggest that openfile and opendir exist alongside open, with openfile being more akin to Perl 5's open or sysopen, and open being a bit more dwimmy. But in general, most of the differences that you mention are things that ought to be addressed in the resulting iterators, not in the creating statement. No, a directory handle will not behave exactly like a file handle. But then, a file handle doesn't behave exactly like standard in or standard out, either (last I checked, Perl 5 won't do anything useful if you say seek STDIN, 0, SEEK_END). -- Jonathan Dataweaver Lang
Re: Should a dirhandle be a filehandle-like iterator?
JL == Jonathan Lang [EMAIL PROTECTED] writes: JL Well, I did suggest that openfile and opendir exist alongside JL open, with openfile being more akin to Perl 5's open or JL sysopen, and open being a bit more dwimmy. JL But in general, most of the differences that you mention are things JL that ought to be addressed in the resulting iterators, not in the JL creating statement. No, a directory handle will not behave exactly JL like a file handle. But then, a file handle doesn't behave exactly JL like standard in or standard out, either (last I checked, Perl 5 JL won't do anything useful if you say seek STDIN, 0, SEEK_END). well, that seek failure is a result of the stream nature of stdin and not a failure of perl. remember that open and much of the i/o layers (regardless of perl I/O's rewrite) are just wrappers around the OS and libc calls. i don't see how to dwim them all together (but IO::All does that in a wacky dwim way). i have never felt the need for super smart iterators so i can change looping over lines to looping over a dir. maybe you might have a set of filenames in file vs a dir of names. but i just don't run into that need. sometimes mappings like that are just overkill IMO. enough from me on this. as with the rest of p6 i will work with whatever is decided by @larry. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
