Pattern negation

[kormat]

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:

/pattern1/ {
  do pattern1 stuff
}
/pattern2/ {
  do pattern2 stuff
}
otherwise {
  do other stuff
}

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:

/pattern1/ {
  do pattern1 stuff
} else {
  /pattern2/ {
    do pattern2 stuff
  } else {
    do other stuff
  }
}

[jaqx0r]

There's no negative matching, but the else or otherwise clause looks like a
good idea.

On Thu, 7 Apr 2016, 04:07 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:

/pattern1/ {
do pattern1 stuff
}
/pattern2/ {
do pattern2 stuff
}
otherwise {
do other stuff
}

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:

/pattern1/ {
do pattern1 stuff
} else {
/pattern2/ {
do pattern2 stuff
} else {
do other stuff
}
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#18

[kormat]

I've been trying to map out the grammar of the existing language. Here's what i have so far:
https://gist.github.com/kormat/33bfceedecaea2b36effc8eeca650727

[jaqx0r]

I'd totally forgotten about this request. I think I can get to it this
weekend. Thanks for the patch!

On Tue, 19 Apr 2016, 07:19 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:
https://gist.github.com/kormat/33bfceedecaea2b36effc8eeca650727

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#18 (comment)

[jaqx0r]

That gist looks pretty accurate. The transformation from bison grammar
into EBNF should be mechanical.

The only question is, what should the new behaviour look like and act like?

Currently consecutive cond_exprs are executed regardless of their ordering
or prior expression's valyues, i.e. there's no implicit 'else if' on each
line, they're all individual 'if' blcoks. So should we alter that
behaviour to break out at the first successful one, as if they were
mutually exclusive, or should an 'otherwise' expression match only if no
other expression does?

I think the least surprising behaviour is the 'only if no other', but
that's less elegant to implement than the single-branch.

A more elegant implementation would require letting the user specify where
the 'else if' and 'else' clauses go, but that makes the language more
verbose.

On 20 April 2016 at 10:11, Jamie Wilkinson jaq@spacepants.org wrote:

I'd totally forgotten about this request. I think I can get to it this
weekend. Thanks for the patch!

On Tue, 19 Apr 2016, 07:19 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:
https://gist.github.com/kormat/33bfceedecaea2b36effc8eeca650727

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#18 (comment)

[jaqx0r]

I just realised that this is a switch that doesn't terminate on first match
(like Go's own); the 'otherwise' is the default rule. This becomes much
easier.

On 24 April 2016 at 20:27, Jamie Wilkinson jaq@spacepants.org wrote:

That gist looks pretty accurate. The transformation from bison grammar
into EBNF should be mechanical.

The only question is, what should the new behaviour look like and act like?

Currently consecutive cond_exprs are executed regardless of their ordering
or prior expression's valyues, i.e. there's no implicit 'else if' on each
line, they're all individual 'if' blcoks. So should we alter that
behaviour to break out at the first successful one, as if they were
mutually exclusive, or should an 'otherwise' expression match only if no
other expression does?

I think the least surprising behaviour is the 'only if no other', but
that's less elegant to implement than the single-branch.

A more elegant implementation would require letting the user specify where
the 'else if' and 'else' clauses go, but that makes the language more
verbose.

On 20 April 2016 at 10:11, Jamie Wilkinson jaq@spacepants.org wrote:

I'd totally forgotten about this request. I think I can get to it this
weekend. Thanks for the patch!

On Tue, 19 Apr 2016, 07:19 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:
https://gist.github.com/kormat/33bfceedecaea2b36effc8eeca650727

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#18 (comment)

[kormat]

I think the 'otherwise' idea is probably a bad one :) Here's what i'm currently thinking, which just requires a single else keyword (as the if is already implicit):

/pattern1/ {
  do pattern1 stuff
} else /pattern2/ {
  do pattern2 stuff
} else {
  do other stuff
}

[kormat]

Actually even the pattern doesn't have to be optional. A trailing else /./ would match everything.

[kormat]

The EBNF then would be:

<conditional statement> ::= <cond> <compound statement> ["else" <conditional statement>]

which is definitely easy to implement in the parser. I haven't looked at the compiler though.

[jaqx0r]

I just had a horrible thought: you could emulate this in 'usrrspcae' with
another variable, set to 0 and increment it in any code block in the
switch, then the 'otherwise' becomes another cond at the bottom:

$otherwise == 0 { ... }

:)

I'm going to give this some more thought; I like the switch better than the
explicit else for the general case. But it seems you only need an else
clause for a single cond statement?

On Sun, 24 Apr 2016, 20:40 Stephen Shirley notifications@github.com wrote:

The EBNF then would be:

::= ["else" ]

which is definitely easy to implement in the parser. I haven't looked at
the compiler though.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#18 (comment)

[kormat]

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 (/./{ <switch stuff> }).

[kormat]

@jaqx0r - I've sent a proof-of-concept PR for this: #23.

[kormat]

#23 updated now to be less POCy.

[jaqx0r]

I thought about it. Por que no los dos? If you only want to write a
single if/else epression, then adding otherwise would make you type more:
You first have to wrap both conditions in a block:

{
/foo/ {
foo++
}
otherwise {
bar++
}
}

/unrelated to foo or bar/ {
..
}

On 24 April 2016 at 20:57, 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 (/./{
}).

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#18 (comment)

[jaqx0r]

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.

[kormat]

https://github.com/google/mtail/wiki/Language probably needs a major rewrite anyway. I've already added a few things it was missing (like hidden, and const). I'll add otherwise there now in any case.

[kormat]

@jaqx0r - here's a suggested update to the language wiki page: https://gist.github.com/kormat/c7770b648e9f7d8d767268b6287d5b95

[jaqx0r]

Thanks again!

On Thu, 28 Apr 2016, 04:16 Stephen Shirley notifications@github.com wrote:

@jaqx0r https://github.com/jaqx0r - here's a suggested update to the
language wiki page:
https://gist.github.com/kormat/c7770b648e9f7d8d767268b6287d5b95

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#18 (comment)