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

Robin Sommer robin at icir.org
Tue Dec 13 10:52:55 PST 2016


> >    type result = record {
> >      error: failure &optional;
> >      value: any &optional;
> >    }

I don't really like using a record like that, as that would associate
specific semantics with what's really a user-definable type. I.e.,
we'd hardcode into the language that the record used here needs to
have exactly these fields. On top of that, it also feels rather clumsy
to me as well. Indeed it's one of the things I don't like about the
current Broker framework API (which currently has to do it that way
just because there's no better mechanism). My draft proposal extends
opaque types to support conversion to boolean to allow for more
elegant error checks. We could generalize that to support other data
types as well, although I don't really see a need for going beyond
opaque right now (assuming we also add the cast operator, per the
proposal, so that we aren't passing anys around).

> With the proposed monad, you could factor the implementation of the
> check function check into a single line:     
> 
>   local r = put(store, key, test(lookup(store, key)));

Honestly, I think this operates on a level that's quite beyond any
other concepts that the language currently offers, and therefore
doesn't really fit in. I'm pretty certain this wouldn't really enter
the "active working set" of pretty much any Bro user out there. For
the time being at least, explicit error checking seems good/convinient
enough to me.

> r$error == timeout

> Based on how flexible we design the type in r$error, it can represent
> all sorts of errors.

That's a piece that I like: Being able to flag different error types.
Maybe the conversion to bool that I proposed originally should really
be a conversion to a dedicated error type, so that one can
differentiate what happened. I need to think about it, but that could
eliminate the need for simply aborting the event handler on timeout
(which in turn would help with the problem that Bro isn't good at
aborting code)

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin


More information about the bro-dev mailing list