[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)
NOTICE(...);
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:
do
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.
Matthias
More information about the bro-dev
mailing list