-
-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starting work on negation, wip #106
Conversation
I could change all that to have |
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.
It would be simpler to just call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good start!
You'll also need to update the visitors.
BTW, if you want to join my channel in the Gophers Slack, there's a little group of us working on Participle :) |
Thanks for this by the way, looking good! |
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 Also, I'm a bit puzzled by the depth in the stringer(). What is its objective ? |
I reverted my tentative changes in stringer(), but the thing is if I define A '...' would be nice, or even better have everything on display. I'm just not sure how depth is supposed to work. |
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. |
No I think the approach is sound.
Sounds reasonable.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty close. I'm happy to merge once my comments are addressed. Thanks!
@@ -282,6 +284,18 @@ func (g *generatorContext) parseGroup(slexer *structLexer) (node, error) { | |||
return &group{expr: disj}, nil | |||
} | |||
|
|||
// A token negation | |||
// | |||
// Accepts both the form !"some-literal" and !SomeNamedToken |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment accurate now?
Awesome, thanks! If you want to |
6e2d1a0
to
d97c4b6
Compare
Done ! |
Thanks again :) |
fixes #104 for reference. |
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 ?