Re: But is it intuitive?
On Tue, 14 Sep 2004, Austin Hastings wrote:
I was thinking about removing files this morning, and realized that I
wish rm supported inclusion/exclusion.
In particular, I wanted to remove * but not Makefile (since my
Makefile uses lwp-download to re-fetch the source code, etc.)
It occurred to me to wonder: can P6's cbut do the same thing?
That is, can I say:
$my_rex = qr/fo*/ but not 'foo';
while () {
unlink if /$my_rex/;
}
The word junction came to my mind as I read your mail.
$my_rex = qr/fo*/ qr:not/foo/;
(I don't think that :not is the option to negate, but there must be some
syntax that works)
I am not saying this is a better way to do it, but just another way that
seems to do the same thing in the same way.
In general, what needs to be done to support this 'but, used as part of
a boolean'?
--abhijit
Re: But is it intuitive?
On 2004-09-14 at 08:40:55, Austin Hastings wrote: In particular, I wanted to remove * but not Makefile (since my Makefile uses lwp-download to re-fetch the source code, etc.) Well, you can, depending on your shell: in ksh: rm !(Makefile) in bash: ditto, but you have to turn on the extglob option first with shopt -s extglob in csh: think you're out of luck here. Note that ksh/bash support multiple exclusions via alternation: rm !(Makefile|configure|config.in) -Mark
Re: But is it intuitive?
Abhijit Mahabal writes:
On Tue, 14 Sep 2004, Austin Hastings wrote:
I was thinking about removing files this morning, and realized that I
wish rm supported inclusion/exclusion.
In particular, I wanted to remove * but not Makefile (since my
Makefile uses lwp-download to re-fetch the source code, etc.)
It occurred to me to wonder: can P6's cbut do the same thing?
That is, can I say:
$my_rex = qr/fo*/ but not 'foo';
while () {
unlink if /$my_rex/;
}
The word junction came to my mind as I read your mail.
$my_rex = qr/fo*/ qr:not/foo/;
Judging from this, maybe we ought to have :not.
Anyway, it's still possible:
$my_rex = rx/fo*/ none(rx/^foo$/);
Luke
Re: But is it intuitive?
Luke Palmer wrote: Judging from this, maybe we ought to have :not. Anyway, it's still possible: $my_rex = rx/fo*/ none(rx/^foo$/); For sure. On a side note, there should be a negating match operator for use inside: rx/\d+/ none(rx/1984/) could get awfully long if you had to handle several exceptions. I like rx:not, though -- a little easier to read IMO. =Austin
Re: But is it intuitive?
On Tue, 2004-09-14 at 10:11, Abhijit Mahabal wrote:
On Tue, 14 Sep 2004, Austin Hastings wrote:
That is, can I say:
$my_rex = qr/fo*/ but not 'foo';
The word junction came to my mind as I read your mail.
$my_rex = qr/fo*/ qr:not/foo/;
Of course, the regex itself can do this:
qr{(fo*) ({$1 ne 'foo'})}
This is probably the superior option, as it can backtrack, where the
others cannot. Thus for the string foo you would match fo because
you find foo first, and it fails, causing the first subexpression to
backtrack, but you can still match fooo correctly on the first try.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: But is it intuitive?
Aaron Sherman skribis 2004-09-14 14:02 (-0400):
qr{(fo*) ({$1 ne 'foo'})}
What is the second set of parens for? Will the following suffice?
rx/ (fo*) { $1 ne 'foo' } /
And it is because of the lack of anchors that this won't work as
expected?
rx/ !before foo fo* /
Juerd
Re: But is it intuitive?
On Tue, Sep 14, 2004 at 02:02:22PM -0400, Aaron Sherman wrote:
: Of course, the regex itself can do this:
:
: qr{(fo*) ({$1 ne 'foo'})}
Er, at the moment bare closures don't care about their return value,
so as it currently stands, you'd want something more like:
rx/(fo*) {fail if $1 eq 'foo'}/
or
rx/(fo*) ($1 ne 'foo')/
But yes, backtracking is a decent way to handle it.
Larry
Re: But is it intuitive?
On Tue, Sep 14, 2004 at 08:30:45PM +0200, Juerd wrote:
: Aaron Sherman skribis 2004-09-14 14:02 (-0400):
: qr{(fo*) ({$1 ne 'foo'})}
:
: What is the second set of parens for? Will the following suffice?
:
: rx/ (fo*) { $1 ne 'foo' } /
Bare closures are used only for their side effects in the current design.
It's vaguely possible that we could recognize a top level boolean operator
and do something different, but there are problems with that approach.
: And it is because of the lack of anchors that this won't work as
: expected?
:
: rx/ !before foo fo* /
No, the f pretty well anchors the front of it in any case. It's the
other end that is the problem. Your solution disallows fooo.
You'd have to say something like:
rx/ !before foo !before o fo* /
Larry
Re: But is it intuitive?
On Tue, 2004-09-14 at 14:40, Larry Wall wrote:
On Tue, Sep 14, 2004 at 02:02:22PM -0400, Aaron Sherman wrote:
: Of course, the regex itself can do this:
:
: qr{(fo*) ({$1 ne 'foo'})}
Er, at the moment bare closures don't care about their return value,
so as it currently stands, you'd want something more like:
rx/(fo*) {fail if $1 eq 'foo'}/
Dang, where's that Perl 6 compiler when I need it to clear up this sort
of thing? ;-)
Thanks for the correction. I notice I fell for the qx vs rx thing
too. Heh, old habits die hard.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
