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

[Robin Sommer]

Sounds like agreement on most suggestions, I'll update the web page
shortly with the conclusions.

Couple further comments:

On Tue, Dec 06, 2016 at 20:43 +0000, Jon wrote:

> I consistently typed "(v as T)$foobar” faster.

Personally, I see this more as a question of readability (as opposed
to typeability :). But it's a matter of taste, and I'd be fine with
using "as" instead of "cast<>".

On Tue, Dec 06, 2016 at 03:17 -0800, Matthias wrote:

> How is a timeout different from a failed computation due to a different
> reason (e.g., connection failure, store backend error)?

I'm thinking such errors need to be addressed by the function itself,
using whatever mechanism it deems appropriate (e.g., signaling trouble
through its return value). The problem is that we don't have any
further error handling mechanisms (e.g., exceptions) in the language
right now (that's a project for some other time). I see timeouts as
different as that's something the function itself may have a hard time
catching internally, if at all; we couldn't rely on that. It's kind of
last line of defense against trouble: if for whatever reason the
function ends up never returning, we'll catch it and clean up at
least.

>  asynchronous operation. More generally, we need well-defined
>  semantics for composing asynchronous computations.

I think this would make sense only if we already had some model for
propagating errors as part of the language. In the absence of that, I
don't really see much to do here. For the normal (non-error) case,
return values are just passed along as expected. And in the abnormal
error case, there's not much else to do than abort the whole event
handler.

Robin

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