How do C and C differ with respect to backtracking? For instance,
foobar ~~ / [a..z]+ [ ... ] /;
Both sides of the C happen in parallel, so I would guess that they
both match foo then stop. Please correct me if that's wrong.
Were we using the procedural conjunction:
foobar ~~ / [a..z
Jonathan Scott Duff wrote:
How do C and C differ with respect to backtracking? For instance,
foobar ~~ / [a..z]+ [ ... ] /;
Both sides of the C happen in parallel, so I would guess that they
both match foo then stop. Please correct me if that's wrong.
As written, this match would fail
a
: conjunctional match is found...]
:
: Or it's much simpler than that and both of the regexes above just fail
: because of the greediness of C+ and there is no intra-conjunction
: backtracking.
:
: I think we definitely allow intra-conjunction backtracking.
: PGE implements it that way.
That's
On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote:
Yow. ICATBW.
The what now?
-'f
, but with backtracking could
: eventually match foobar. Do the longest-token semantics
: in this case cause the RHS to be dispatched first, even
: though the token declaration of the LHS _could_ match a
: longer token prefix?
Yow. ICATBW. Non-greedy matching is somewhat antithetical to
longest-token
On Thu, Sep 06, 2007 at 03:49:42PM -0700, Larry Wall wrote:
: On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: : I agree. One thought I had was that perhaps non-greedy matching
: : could also terminate the token prefix.
:
: Well, that's more or less arguing it the other way.
On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: I agree. One thought I had was that perhaps non-greedy matching
: could also terminate the token prefix.
Well, that's more or less arguing it the other way. It kind of assumes
your fooba-ish arguments are smart enough to test
Consider this code:
if (specific_condition())
{
if (detail())
{
act();
}
}
elsif (general_condition())
{
act();
}
Logically, this turns into:
if ((my $sc = specific_condition()) detail())
|| (!$sc general_condition())
{
act();
}
Both look
Austin Hastings wrote:
Both look horrible, of course. I'd like to rewrite them as
if (specific_condition() :: detail()) || general_condition()
{
act();
}
so that if specific_condition() succeeded, it would cause the entire
expression to fail if detail() failed.
The use of :: comes, of
All you really need is:
if ( specific_condition() ? detail() : general_condition() )
Oops! That's the Perl 5 version. In Perl 6, of course, it's:
if ( specific_condition() ?? detail() :: general_condition() )
Which means you *do* get to use the :: after all!
(Just not where you
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Since paren's aren't required with keywords, can they still serve as rex
delimiters?
No. For other syntactic reasons parens aren't allowed as rule
delimiters at all. And only /.../ delimit raw matches. Every other
[EMAIL PROTECTED] (Austin Hastings) writes:
if (specific() ?? detail1() detail2() :: general()) {...}
For some value of correct I suppose. Using ??:: within an if/else context
makes my skin crawl, stylistically. :-(
Ah, then use if!
if (if(specific()) { detail() } else { general()
On Fri, Apr 02, 2004 at 03:05:30PM +0100, Simon Cozens wrote:
: [EMAIL PROTECTED] (Austin Hastings) writes:
:if (specific() ?? detail1() detail2() :: general()) {...}
:
: For some value of correct I suppose. Using ??:: within an if/else context
: makes my skin crawl, stylistically.
On Fri, 2004-04-02 at 10:01, Larry Wall wrote:
Even an almost purely RPN language
like Japanese likes to use honorifics and/or a bunch of particles to
mark the ends of its sentences, yo?
Hai, and it's not just there to help in error reporting. Imagine the
case:
if if if if if ...
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Fri, Apr 02, 2004 at 03:05:30PM +0100, Simon Cozens wrote:
: [EMAIL PROTECTED] (Austin Hastings) writes:
:if (specific() ?? detail1() detail2() :: general()) {...}
:
: For some value of correct I suppose.
Backtracking syntax includes:
:, ::, :::, commit, cut
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what
[EMAIL PROTECTED] (Me) writes:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, now just how wide a
scope am I backtracking when there's three colons?.
Why would newbies be writing three
[EMAIL PROTECTED] (Me) writes:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, now just how wide a
scope am I backtracking when there's three colons?.
Why would newbies be writing
Backtracking syntax includes:
:, ::, :::, commit, cut
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, now just how wide a
scope am I backtracking when there's three colons?.
What
[EMAIL PROTECTED] (Markus Laire) writes:
While commit and cut don't follow same syntax, I don't really see
any better solutions.
commit is sufficiently hard that it musn't be confused with the
colon series.
I wonder if might be usefull instead of commit with proper
On 22 Sep 2002 at 21:06, Simon Cozens wrote:
[EMAIL PROTECTED] (Markus Laire) writes:
While commit and cut don't follow same syntax, I don't really see
any better solutions.
commit is sufficiently hard that it musn't be confused with the
colon series.
Yes, I didn't think that enough.
operation, so it's like
the ? non-greedy modifier. Is that incorrect? Everything else does
something when backtracked over; the only thing : has in common with
them is that it has something to do with backtracking.
Btw, is /:/ ambiguous? I can't remember if there's any way a /pattern/
can be followed
, to get a rule in a closure to even continue matching from the same
point in the string, you would need to write:
rule expr1 {
term { m:cont/operators/ or fail } term
}
Backtracking would just step back over the rule as if it were atomic
(or followed by a colon
Damian Conway wrote:
rule expr1 {
term { m:cont/operators/ or fail } term
}
Backtracking would just step back over the rule as if it were atomic
(or followed by a colon).
Ok, thanks. (The followed by a colon is just to explain the behavior,
right? It's illegal to follow
[NOTE: BCCing off-list to protect private email addresses]
On Fri, 2002-08-30 at 09:07, Ken Fox wrote:
Does the following example backtrack into foo?
rule foo { b+ }
rule bar { a foo b }
This was the bit that got me on-board. I did not see the need for
backtracking into rules until
to get backtracking.
In the normal case it's a no-op, since closures don't normally get
control back when backtracked over.
: After talking to Aaron yesterday, I was wondering if sub-rules are
: meant to backtrack at all.
:
: Does the following example backtrack into foo?
:
:rule foo { b
continuation games of some sort to get backtracking.
Apoc 5 has It is an error to use : on any atom that does no
backtracking. Code blocks don't backtrack (at least that's what
I understood Damian to say). Are zero width atoms treated specially?
And can you give me an example of a continuation game
On Fri, 30 Aug 2002, Ken Fox wrote:
: Apoc 5 has It is an error to use : on any atom that does no
: backtracking. Code blocks don't backtrack (at least that's what
: I understood Damian to say).
Code blocks don't backtrack *by default*. But you can do anything
in a closure.
: Are zero width
Larry Wall wrote:
There's a famous book called Golf is Not a Game of Perfect.
Well now I'm *totally* confused. I looked that up on Amazon
and it has something to do with clubs and grass and stuff. That's
completely different than what I thought golfing was. ;)
Seriously, though. I have a
back-
tracking so that { code } can fail, succeed (not fail), or succeed and
commit. Right now we can follow { code } with ::, :::, etc. but that does
not allow much control. I'm a little afraid of what happens in an LL(Inf)
grammar if backtracking states aren't aggressively pruned.
- Ken
if backtracking states aren't aggressively pruned.
Well, if /.../ is returning a result object (Let's say
CORE::RX::Result), then I would imagine it's an easy enough thing to let
you create your own, or return the one from a rule that you invoke.
e.g.:
rule { term { /operators/.commit(1) or fail
Aaron Sherman wrote:
rule { term { /operators/.commit(1) or fail } term }
The hypothetical commit() method being one that would take a number and
That would only be useful if the outer rule can backtrack into the
inner /operators/ rule. Can it?
I agree with you that a commit method
.:
rule foo { b : }
rule bar { a foo+ b }
abb =~ /bar/
will match, because the foo rule never needs to backtrack. If foo had
used C commit , then you'd fail, but that's a horse of a different
animal.
The goal was to dynamically cause backtracking over inline code to fail.
hi,
So how is that different from:
do BLOCK1 until do BLOCK2
It's the same.
But the real fun starts when blocks and functions can suspend and
resume.
{ ...
# Return value and suspend.
suspend $i;
# Next iteration will resume here
...
} andthen { ... };
=head1 REFERENCE
Icon language brief intro :
http://www.cs.arizona.edu/icon/intro.htm
Jonathan Scott Duff wrote:
On Tue, Aug 15, 2000 at 05:47:53PM -0600, Nathan Torkington wrote:
I want
@result = @a || @b;
to be like:
(@result = @a) or (@result = @b);
That's what all my students keep expecting it to mean.
And that's what I keep wishing it meant too.
On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote:
I like the idea of adding the context-aware operators, but I don't
think I'd use them as often as I use "the number of things in the
array". I think most Perl programmers would be in the same camp.
Unless you can show a
Mark Cogan wrote:
At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
It seems obvious that @a should be the whole array @a, not the size of
the
array. If I want to check the size of @a, I should have to do so
explicitly,
with scalar or $#.
This is non-obvious if you think that || is a flow
Mark Cogan wrote:
At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
You are missing the beauty of vector/matrix operations.
No, I'm not; I'm opining that the vast majority of Perl users don't need
to
do vector/matrix ops, and that they don't belong in the core.
The vast majority of Perl 5
There's also the cut operator which I didn't see mentioned in the RFC.
It blocks backtracking so that something like this:
B1 andthen B2 andthen cut B3 andthen B4 andthen B5
wouldn't backtrack to B2 once it forwardtracked to B3.
]- I tried minimalistic approach as small as possible
They behave similarly like , ||, and, or operator with one main
distinction they "backtrack" for example:
{ block1 } Bandthen { block2 };
This would be a good use of the to-be-liberated = operator:
{ block1 } = { block2 };
In any case, "andthen" doesn't seem like a good choice.
raptor wrote:
]- I tried minimalistic approach as small as possible additions to the
Perl
language, we get only the "backtrack" mechanism i.e. something that is
harder or slower to be done outside of the perl core.
The rest should be done outside . (I too want all in the core)
I don't
resumption of subroutines. Do the proposed backtracking operators buy
anything that do/until/coroutines don't provide?
"MC" == Mark Cogan [EMAIL PROTECTED] writes:
is equivalent to
@a = (\$a, \$b, \$c);
rather than what you wrote.
MC Ah, so it is. I'd argue that that's broken and should be handled with map
MC or for.
Err, That's not an accident. Larry designed that in.
chaim
--
Chaim Frenkel
Damian Conway wrote:
So how is that different from:
do BLOCK1 until do BLOCK2
???
Because if BLOCK1 ever evaluates to False, the operation terminates.
It's more like
do { r = f1() } until ( not r or f2() );
--
John Porter
On Wed, Aug 16, 2000 at 07:42:33PM +1000, Jeremy Howard wrote:
raptor wrote:
]- I tried minimalistic approach as small as possible additions to the
Perl
language, we get only the "backtrack" mechanism i.e. something that is
harder or slower to be done outside of the perl core.
The rest
Johan Vromans wrote:
So how is that different from:
do BLOCK1 until do BLOCK2
It's the same.
No, not quite. See my other post.
--
John Porter
iVAN Georgiev [EMAIL PROTECTED]:
They behave similarly like , ||, and, or operator with one main
distinction they "backtrack" for example:
{ block1 } Bandthen { block2 };
This would be a good use of the to-be-liberated = operator:
{ block1 } = { block2 };
In any case, "andthen"
, placing the
result in @result.
I'm no Prolog guru, so feel free to correct me if I'm missing something
here.
I think you're missing the backtracking part (I'm no guru either).
As I understand things:
BLOCK1 andthen BLOCK2
evaluates BLOCK1 and then if BLOCK1 evaluates to "
As I understand things:
BLOCK1 andthen BLOCK2
evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
BLOCK2. If BLOCK2 evaluates to "true" we're done. If BLOCK2
evaluates to "false", then BLOCK1 is re-evaluated.
So how is that different from:
Jeremy Howard writes:
@result = @a || @b;
Which applies '||' component-wise to elements of @a and @b, placing the
result in @result.
*Ptui* That's not how *I* want || to behave on lists/arrays.
I want
@result = @a || @b;
to be like:
(@result = @a) or (@result = @b);
That's what
Nathan Torkington wrote:
Jeremy Howard writes:
@result = @a || @b;
Which applies '||' component-wise to elements of @a and @b, placing the
result in @result.
*Ptui* That's not how *I* want || to behave on lists/arrays.
I want
@result = @a || @b;
to be like:
(@result = @a)
At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
Jeremy Howard writes:
@result = @a || @b;
Which applies '||' component-wise to elements of @a and @b, placing the
result in @result.
*Ptui* That's not how *I* want || to behave on lists/arrays.
I want
@result = @a || @b;
to be
At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
Mark Cogan wrote:
At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
Jeremy Howard writes:
@result = @a || @b;
Which applies '||' component-wise to elements of @a and @b, placing
the
result in @result.
*Ptui* That's not
You are missing the beauty of vector/matrix operations. The math folks
really would like to be able to describe the operation wanted and have
perl do the optimization.
Would adding another character be helpful
@result = @a x|| @b?
@result = @a ||| @b?
or perhaps a modifier?
At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
You are missing the beauty of vector/matrix operations.
No, I'm not; I'm opining that the vast majority of Perl users don't need to
do vector/matrix ops, and that they don't belong in the core.
The math folks
really would like to be able to
"MC" == Mark Cogan [EMAIL PROTECTED] writes:
MC What should:
MC @a = defined @a;
MC return?
Counter example:@a = \($a, $b, $c);
(Not really a full fledged counter example since it is a liter list.)
Treating || as a special case is asking for trouble. If you want a flow
control
At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
"MC" == Mark Cogan [EMAIL PROTECTED] writes:
MC What should:
MC @a = defined @a;
MC return?
Counter example:@a = \($a, $b, $c);
I guess I'm missing the point; how is this different from
@a = [$a,$b,$c];
which works to be the same as
On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
Counter example:@a = \($a, $b, $c);
I guess I'm missing the point; how is this different from
@a = [$a,$b,$c];
Well, I've lost the point of this thread, but
@a =
At 11:05 PM 8/15/00 -0500, Jonathan Scott Duff wrote:
On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
Counter example:@a = \($a, $b, $c);
I guess I'm missing the point; how is this different from
@a = [$a,$b,$c];
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Backtracking
=head1 VERSION
Maintainer: iVAN Georgiev [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 104
=head1 ABSTRACT
Backtraking mechanism is core
61 matches
Mail list logo
