> On Mon, Mar 17, 2003 at 11:17:21AM -0700, Luke Palmer wrote: > >> > <name(expr)> # call rule, passing Perl args > >> > { .name(expr) } # same thing. > >> > >> Considering perl can't sanely know how to backtrack into a closure, > >> wouldn't { .name(expr) } be equal to <name(expr)>: instead? > > > >Nope. <name(expr)>: is equivalent to { .name{expr} }: . It does know > >how to backtrack into a closure: it skips right by it (or throws an > >exception through it... not sure which) and tries again. > >Hypotheticals make this function properly. > > That sounds very unlikely, and is also contradicted by earlier messages, > like: "closures don't normally get control back when backtracked over" > -- Larry Wall in http://nntp.x.perl.org/group/perl.perl6.language/10781 > > Hypothetical variables make things work right when backtracking *over* a > closure, but certainly not *into* one. > > I'm talking about cases like: > > rule foo { a+ } > rule bar { { .foo } ab } > > my intuition says this equals { [a+]: ab } and hence never matches
Oh, right, sorry. That was a braino on my part. That is what I meant, but I didn't realize that { .name{expr} }: was redundant. > > rule somerule($0) {} > > I meant ofcourse as a method (since rules are just methods if I understood > correctly); to do the matching yourself rather than with perl 6 regex. Ohh. That has to do with the parse object, which hasn't been covered yet. The *signature* is probably just: grammar FooBar { method somerule() {...} } Where the invocant would be a FooBar, which presumably inherits from something like ParseObject. > >> Considering <prop> means "matches a character with property prop", it > >> seems to me <!prop> would mean the ZERO-WIDTH assertion "does not match a > >> character with property prop", rather than "match a character without > >> property prop". > > > >Right. It has to be. There is no way to implement it in a > >sufficiently general way otherwise. > > Hence the example of saying \P{prop} becomes <!prop> is wrong; it actually > becomes <-prop>, right? Probably. Larry might have something different in mind, but what you've said seems the obvious solution at the moment. > >> While I'm on the subject.. why not allow <> as the match-always assertion? > >> It might conflict with huffman encoding, but I certainly don't think <> > >> could ethically mean anything other than this. And <!> would ofcourse be > >> the match-never assertion. > > > >You could always use <(1)> and <(0)>, which are more SWIMmy :) > > Ick, ugly; I'd rather use <null> and <!null> than those, but <> and <!> > are shorter, and have (to me) fairly obvious meanings. But it was just a > random suggestion; I'm not going to actively try to advocate them if > they're not liked :-) <null> and <!null>, good idea. I didn't even think of that. I think <> and <!> are violating the whole point of introducing <null>: that it was unclear what was meant by //, and it's too easy to do. They're not quite as bad, but it doesn't seem right. <null> and <!null> are good. (Forgive me for being a little braindead; it's been a while since I've read A5) Luke