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
Larry wrote:
> sub while (&test is rx//, &body);
>
> or some such. That probably isn't sufficient to pick out of Perl's
> grammar rather than the current lexical scope.
I love the idea, but the property name needs to be more expressive
(and Huffmanly longer). Maybe:
sub while (
On Thu, 29 Aug 2002, Thomas A. Boyer wrote:
: Am I getting this straight?
As straight as any of us are getting it thus far. :-)
The process is intended to be convergent. That doesn't guarantee it
will converge, but that's the intention.
When I'm playing golf, I always expect to knock the ball
Don't forget you can parameterize rules with subrules. I don't see
any reason you couldn't write a
kind of rule and do whatever you like with the submatched bits.
Larry
Luke Palmer wrote at Thu, 29 Aug 2002 15:21:57 +0200:
>> The ° character doesn't have any special meaning,
>> that's why I choosed it in the above example.
>> However, it also symbolizes a little capturing
>> and as it isn't filled,
>> it could really symbolize an uncapturing.
>
> Interesting id
On Thu, Aug 29, 2002 at 07:52:42AM -0700, Steve Canfield wrote:
> From: Dan Sugalski [EMAIL PROTECTED]
> >I actually had something a bit more subversive
> >in mind, where the assignment operator for the
> >Date class did some magic the same way we do
> >now when we do math on strings.
>
> I was t
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/
From: Dan Sugalski [EMAIL PROTECTED]
>I actually had something a bit more subversive
>in mind, where the assignment operator for the
>Date class did some magic the same way we do
>now when we do math on strings.
I was thinking a simple general purpose rule. If the variable is
typed, and its class
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
> The ° character doesn't have any special meaning,
> that's why I choosed it in the above example.
> However, it also symbolizes a little capturing
> and as it isn't filled,
> it could really symbolize an uncapturing.
Interesting idea. I'm not sure if I agree with it yet. However, I don't
agr
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
On Wed, Aug 28, 2002 at 10:36:54AM -0700, Larry Wall wrote:
> That is a worthy consideration, but expressiveness takes precedence
> over it in this case. DFAs are really only good for telling you
> *whether* and *where* a pattern matches as a whole. They are
> relatively useless for telling you
13 matches
Mail list logo
