-
Notifications
You must be signed in to change notification settings - Fork 378
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
Pattern negation #18
Comments
There's no negative matching, but the else or otherwise clause looks like a On Thu, 7 Apr 2016, 04:07 Stephen Shirley notifications@github.com wrote:
|
I've been trying to map out the grammar of the existing language. Here's what i have so far: |
I'd totally forgotten about this request. I think I can get to it this On Tue, 19 Apr 2016, 07:19 Stephen Shirley notifications@github.com wrote:
|
That gist looks pretty accurate. The transformation from bison grammar The only question is, what should the new behaviour look like and act like? Currently consecutive cond_exprs are executed regardless of their ordering I think the least surprising behaviour is the 'only if no other', but A more elegant implementation would require letting the user specify where On 20 April 2016 at 10:11, Jamie Wilkinson jaq@spacepants.org wrote:
|
I just realised that this is a switch that doesn't terminate on first match On 24 April 2016 at 20:27, Jamie Wilkinson jaq@spacepants.org wrote:
|
I think the 'otherwise' idea is probably a bad one :) Here's what i'm currently thinking, which just requires a single
|
Actually even the pattern doesn't have to be optional. A trailing |
The EBNF then would be:
which is definitely easy to implement in the parser. I haven't looked at the compiler though. |
I just had a horrible thought: you could emulate this in 'usrrspcae' with $otherwise == 0 { ... } :) I'm going to give this some more thought; I like the switch better than the On Sun, 24 Apr 2016, 20:40 Stephen Shirley notifications@github.com wrote:
|
Ahh. I see your point. Yeah, non-auto-terminating switch does seem better in general. Otherwise (heh) we're tying ourselves to forcing mutually exclusive conditionals. Creating a scope for the switch is also easy ( |
#23 updated now to be less POCy. |
I thought about it. Por que no los dos? If you only want to write a { /unrelated to foo or bar/ { On 24 April 2016 at 20:57, Stephen Shirley notifications@github.com wrote:
|
I've merged your PR. The site's wiki doesn't yet describe the new language; I'll take a PR for that but won't demand it from you. I also want to add the 'else' clause for single cond statements so will keep this issue open until I take that on. |
https://github.com/google/mtail/wiki/Language probably needs a major rewrite anyway. I've already added a few things it was missing (like |
@jaqx0r - here's a suggested update to the language wiki page: https://gist.github.com/kormat/c7770b648e9f7d8d767268b6287d5b95 |
Thanks again! On Thu, 28 Apr 2016, 04:16 Stephen Shirley notifications@github.com wrote:
|
Is there any way to have an action happen if a pattern /doesn't/ match? Go's regex library doesn't support negative-look-ahead, but i can't find any syntax in the mtail language which allows me to work around this.
What i'm trying to do is something like this:
In my case the otherwise bit happens in the absence of the first two. Ideally, being able to chain if/else would be great, but in a pinch a simple 'else' keyword would allow this to be represented as:
The text was updated successfully, but these errors were encountered: