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 pos
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 a
Larry Wall wrote:
> On Fri, 30 Aug 2002, Ken Fox wrote:
> : Ok, thanks. (The "followed by a colon" is just to explain the behavior,
> : right? It's illegal to follow a code block with a colon, isn't it?)
>
> I don't see why it should be illegal--it could be useful if the closure
> has played cont
On Fri, 30 Aug 2002, Ken Fox wrote:
: Ok, thanks. (The "followed by a colon" is just to explain the behavior,
: right? It's illegal to follow a code block with a colon, isn't it?)
I don't see why it should be illegal--it could be useful if the closure
has played continuation games of some sort to
[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 ?
>
>rule foo { b+ }
>rule bar { a b }
This was the bit that got me on-board. I did not see the need for
backtracking into rules until he
Damian Conway wrote:
> rule expr1 {
> { m:cont/@operators/ or fail }
> }
>
> 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 a
Ken Fox wrote:
> A question: Do rules matched in a { code } block set backtrack points for
> the outer rule?
I don't believe so. From A5:
A pattern nested within a closure is classified as its own rule,
however, so it never gets the chance to pass out of a {...} closure.
Indee
On Thu, 2002-08-29 at 10:28, Ken Fox wrote:
> Aaron Sherman wrote:
> > rule { { /@operators/.commit(1) or fail } }
> >
> > 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/
Aaron Sherman wrote:
> rule { { /@operators/.commit(1) or fail } }
>
> 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 woul
On Thu, 2002-08-29 at 08:05, Ken Fox wrote:
> A question: Do rules matched in a { code } block set backtrack points for
> the outer rule? For example, are these rules equivalent?
>
> rule expr1 {
> { /@operators/ or fail }
> }
>
> rule expr2 {
> @operators
> }
>
> And a comm
A question: Do rules matched in a { code } block set backtrack points for
the outer rule? For example, are these rules equivalent?
rule expr1 {
{ /@operators/ or fail }
}
rule expr2 {
@operators
}
And a comment: It would be nice to have procedural control over back-
tracking
11 matches
Mail list logo
