> 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
