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 * [email protected] * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
