> <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
Sounds like continuation-passing style. Yes, you can backtrack through code with continuation-passing style. Continuations have yet to be introduced into the language.
You don't need continuations to do this though, you can do it in plain perl code too. For example:
rule test { <foo> <bar> }
-->
method test (&cont) { .foo({ .bar(&cont) }) }foo gets a closure that represents the rest of the match (bar followed by whatever comes after test) and if it succeeds, invokes the closure hence calling bar. if bar fails, it returns to foo which can then try a different match and call the closure again. If all parts match than the final closure will be called (passed by the match-function to the original rule) which does something to return the final version of the state object to the original called - for example using an exception.
I'm not saying rules will be implemented in such a way, but it's the first thing that comes to mind.
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.
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?
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 :-)
-- Matthijs van Duin -- May the Forth be with you!
