Add function to compute lookahead

[alecthomas]

Repetitions will be unbounded. Everything else should be computable.

[ceymard]

Are you talking about "positive lookahead" ? Because I was about to file an issue about that, as I'm unsure there is something like that.

It would be particularly useful along with "!" (which is starting to actually work with any kind of pattern)

type MyTest struct {
  SomeCoolRule *SubRule `=!('.' String) @@`
} 

This would match SubRule but ONLY if SubRule doesn't start with . 'some-string'

[alecthomas]

This was solely about automatically determining what the required lookahead value for a particular grammar is.

What's the use case for this? Participle already performs lookahead automatically, so normally given multiple cases in a disjunction this kind of behaviour will occur automatically. ie. you'd typically have

type MyTest struct {
  A *string `"." @String`
  B *SubRule `| @@`
}

[ceymard]

I can't really think of anything other than readability right now. I'm not even sure I have ever used a look ahead in any of the grammars I've written.

[mechaneg]

Am I right, that look ahead value is computed automatically now ?

If so, why this disjunction example fails ?

input: "one two"
Error: "unexpected token "two"".
if I'll reorder fields Single and Many in Foo definition everything works fine for both "one" and "one two" inputs

type Foo struct {
	Single *Single `parser:"@@  |"`
	Many   *Many   `parser:"@@"`
}

type Single struct {
	Val string `parser:"@Ident"`
}

type Many struct {
	Vals []string `parser:"@Ident Ident"`
}

[alecthomas]

It is not computed automatically, this ticket is still open.

[mechaneg]

Ok, got it.
Anyway, I tried to increase look ahead value during parser initialization and my previous example still fails.
What's wrong with it?

[alecthomas]

Lookahead only comes into play if a branch fails to match. In your case it successfully matches the first branch and so accepts it. You'll need to reorder your branches.

…

On Tue, Oct 13, 2020 at 8:28 PM mechaneg ***@***.***> wrote: Ok, got it. Anyway, I tried to increase look ahead value during parser initialization and my previous example still fails. What's wrong with it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKGJZ3BIYI2YIDBZKKO23SKQMU7ANCNFSM4Q3SBYIQ> .

[mccolljr]

The addition of Union might make this a bit more complicated. The expr3 example technically requires infinite lookahead to be unambiguous for all possible inputs. In practice a sufficiently large number will have the same result for all reasonable inputs but its something to consider if this feature is still desired