[Bro-Dev] [Proposal] Language extensions for better Broker support

Siwek, Jon jsiwek at illinois.edu
Fri Dec 2 09:00:00 PST 2016


> On Dec 1, 2016, at 9:39 PM, Robin Sommer <robin at icir.org> wrote:
> 
>    https://www.bro.org/development/projects/broker-lang-ext.html
> 
> Feedback welcome, this is just a first draft.

Looks like a big improvement, some ideas:

Not that syntax is super important to nail down right away, but to me, “v as T” syntax is simpler than "as<T>(v)”.

Is there a reason "type(v)” can’t be stored?  I’d probably find it more intuitive if it could, else I can see myself forgetting or making mistakes related to that.  Alternative to even providing “type(v)”, you could have a “v is T” operation and to use an explicit/new “typeswitch (v)” statement instead of re-using “switch (type(v))”.

Between the two switch syntaxes you gave, maybe provide both and allow mixing of syntax between cases.  E.g.:

switch ( type(v)  ) {
    case bool -> b:
        print “it’s a bool, and I need to inspect the value", b;
        break;

    case count:
        print “it’s a count, but I don’t care what the value is, I just wanted to know if it’s a count”;
        break;
}

"Asynchronous executions without when”:  I’d go with an explicit keyword to denote when a handler will yield execution — it makes it easier to understand the behavior of a function at a glance without requiring a perfect memory for what functions cause execution to yield.  Full co-routine support is a nice step to take and this is already similar enough that adding a keyword like “yield” at this point may make it easier to evolve/plan the language into having generalized co-routine support.  It might even be useful to try and spec out the co-routine support now and see how this specific use-case fits in with that.

- Jon



More information about the bro-dev mailing list