Starting work on negation, wip

[ceymard]

Here is a naive interpretation on how the negation could function.

If you want to do it entirely yourself, go ahead, but I'm willing to see this through as I really would like to see it come to fruition and this helps me hone my go funk.

I'm looking for some feedback on that preliminary implementation.

Am I missing something glaring ? Is the clone stuff potentially a performance killer ? Should Parse() be a little more involved ?

[ceymard]

I could change all that to have !( ';' | ',' | SomeToken) by parsing it by hand (not going for parseDisjunction) and having a Parse() that actually peeks and verifies the list passes the check. That would ensure that we forbid anything like !( @'what' ) which would make no sense since for binding we'd rather have @!'lit' or @!(';', ',')

[alecthomas]

Don't worry about the speed of clone, despite what I wrote before :)... I'm going to do an optimisation pass once I'm happy with everything else.

I could change all that to have !( ';' | ',' | SomeToken) by parsing it by hand (not going for parseDisjunction) and having a Parse() that actually peeks and verifies the list passes the check.

It would be simpler to just call parseDisjunction() then walk it to type check it. But I think just supporting ![@]<literal> or ![@]<reference> to start with is a good approach, then we could expand it later if desired.

[alecthomas]

Good start!

You'll also need to update the visitors.

[alecthomas]

BTW, if you want to join my channel in the Gophers Slack, there's a little group of us working on Participle :)

[alecthomas]

Thanks for this by the way, looking good!

[ceymard]

Alright.

So I added some tests, which show so far that the negation has the potential to be pretty flexible.

It seems just parsing a term (with groups, sequences and whatnot) without restrictions has some satisfying results, even when I want to negate sequences (which is probably useful). Are there potential restrictions to address ?

However, I'm ignoring lookahead by not calling Stop() in negation.Parse. I did that because of course, when negating a sequence, I need the lookahead to be at least as big as the potential sequence, but it works if we just ignore that (so that Stop won't Accept my arm if partially matched, thus failing to parse afterwards). Am I missing something ? Is the lookahead size important to prevent the parser from going haywire or something ?

Also, I'm a bit puzzled by the depth in the stringer(). What is its objective ?

[ceymard]

I reverted my tentative changes in stringer(), but the thing is if I define !('tok' 'tok2'), then stringer just won't display 'tok2' since the sequence stops at depth 0 which is attained immediately (so right after the first item).

A '...' would be nice, or even better have everything on display. I'm just not sure how depth is supposed to work.

[ceymard]

BTW, if you want to join my channel in the Gophers Slack, there's a little group of us working on Participle :)

How do I join ? No matter how I try to login, I just can't enter. :(

[alecthomas]

BTW, if you want to join my channel in the Gophers Slack, there's a little group of us working on Participle :)

How do I join ? No matter how I try to login, I just can't enter. :(

Try this link I think? https://invite.slack.golangbridge.org/

I'm in Australia, so I'll be back online in about 9-10 hours.

[alecthomas]

It seems just parsing a term (with groups, sequences and whatnot) without restrictions has some satisfying results, even when I want to negate sequences (which is probably useful). Are there potential restrictions to address ?

No I think the approach is sound.

However, I'm ignoring lookahead by not calling Stop() in negation.Parse. I did that because of course, when negating a sequence, I need the lookahead to be at least as big as the potential sequence, but it works if we just ignore that (so that Stop won't Accept my arm if partially matched, thus failing to parse afterwards).

Sounds reasonable.

Also, I'm a bit puzzled by the depth in the stringer(). What is its objective ?

It's not the recursion depth. The idea is that it displays to the user the next set of options available to them, which is why in the case of "foo" "bar" only "foo" would be displayed.

[alecthomas]

Seems pretty close. I'm happy to merge once my comments are addressed. Thanks!

[alecthomas]

Is this comment accurate now?

[alecthomas]

Awesome, thanks!

If you want to git rebase -i master && git push -f, we can use this PR. Up to you.

[ceymard]

Done !

[alecthomas]

Thanks again :)

[ceymard]

fixes #104 for reference.