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

Matthias Vallentin vallentin at icir.org
Tue Dec 13 04:02:23 PST 2016

> I might prefer just doing the unpacking myself. Having
> separate/explicit checks for each individual return value would
> naturally occur over time anyway (e.g. when debugging, adding extra
> logging, improving error handling).

> How common do you expect async function chains to occur?  Any specific
> examples in mind where auto-chaining is very helpful?  Maybe it’s more
> of a nice-to-have feature than a requirement?

This is a bit of a chicken-and-egg problem: we don't have much use of
when at the moment, because it's difficult to nest. If we provide a
convenient means for composition from the get-go, I'd imagine we see a
quicker adoption of the new features.

The standard workflow I anticipate is a lookup-compute-update cycle.
Here's a half-baked example:

  function test(attempts: count): result {
    if (attempts > threshold)
    return [$value = attempts + 1]; // no error

  function check(..) : result {
    local key = fmt("/outbound/%s", host);
    local r = async lookup(store, key);
    if (r?$error)
      return local?$error;
    return async put(store, key, failed_attempts + 1);

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)));
Conceptually, this is equivalent to "binding" your function calls:

  local r = lookup(store, key)) 
        >>= test 
        >>= function(x: count) { return put(store, key, x); }; // curry

...where >>= would be the bind operator performing error/value
unpacking. Less functional clutter with the "do" notation:

    x1 <- lookup store key
    x2 <- test x1
    x3 <- put store key x2

The last two snippets derail the conversation a bit---just to show where
these ideas come from. 

Note that the function "test" is synchronous in my example and that this
doesn't matter. The proposed error handling makes it straight-forward to
mix the two invocation styles.


More information about the bro-dev mailing list