Language support for constraints/assertions

[neilconway]

There's a common idiom for writing down correctness constraints and assertions:

    fail <= should_not_happen { ... }
    stdio <= fail { ["error!"] }
    _ <= fail { raise BudError }

We might consider adding support for this idiom to the language itself. For a start, it would slightly simplify programs, and make them more uniform. It might also enable us to address some related questions, such as:

• How do errors interact with the module system? If module X is in an error state, how does this impact other modules?
• If accepting input event X in state Y leads to an error state, should we revert the state of the DB and store X somewhere else, then continue processing?
• Should we provide a runtime mode that disables assertions/constraints, on the grounds that it (a) hurts performance (b) doesn't enable useful error recovery (... unless we fixup the error recovery story, that is)

[neilconway]

I'm thinking about implementing support for this soonish. If anyone has any input on how this feature should be designed, let me know (I'm inclined to skip thinking about how errors should interact with the module system).

[jhellerstein]

Please offer a design we can discuss. Some questions from my end:

• How does local-node constraint violation interact with temporal semantics? Now/next/later?
• What is the fate of the state in a failed node?
• What does a "catch" block look like in Bloom, and how does it interact with mid-tick state?
• If we choose to fail-stop and drop all state on failure, should the "catcher" be a separate Bloom instance on a separate port?

And maybe most importantly:

• What kind of semantics and program analysis do we want to support for exception handling logic vis a vis the rest of a program?

Joe

On Feb 1, 2013, at 11:18 PM, Neil Conway notifications@github.com wrote:

I'm thinking about implementing support for this soonish. If anyone has any input on how this feature should be designed, let me know (I'm inclined to skip thinking about how errors should interact with the module system).

— Reply to this email directly or view it on GitHub.