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
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
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,
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
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
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
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,
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.
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
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
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
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 _)
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
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
-
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
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
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
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
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 -
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
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
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
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
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
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
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
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'
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
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
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,
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,
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
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
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
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
35 matches
Mail list logo
