Ways to make a contract not fail immediately?

[suimong]

Is there a way to make broken contract not fail immediately? e.g. I'm writing a contract that's in effect composed of 4 smaller contracts, and if two of them would fail on a value, I'd like nickel to apply all 4 contracts separately without failing but let me to collect the error info, and when I manually invoke std.fail_with I could let the user know which two contracts passed and which two contracts failed in the error message.

[yannham]

Currently there's no way to catch a contract error, if that what's you're referring to. One possibility would be to use predicates instead - that is, have your actual contract code be foo_predicate = fun value => ...returns some boolean, or maybe some boolean + metadata for label custom errors..., and just do Foo = std.contract.from_predicate foo_predicate (or your own from_predicate variant if you want to propagate error message/notes). If the predicate is your original source of truth, then you can easily write a another predicate that checks for foo_predicate, bar_predicate, etc. - that is any boolean combination.

I'm not sure we'll have some form of general try-catch mechanism for contracts. This has an important impact on the rest of the language. A middle ground would be that there is a better distinction of contracts that are just predicates - for example Number, Bool, String, and any contract build from from_predicate - from which we could extract the predicate back with some stdlib helper.

[yannham]

It's not obvious to implement while maintaining backward compatibility, instead. Though a possible middle ground would be to just introduce a new specific object just for contract coming from predicates, and just make them act like functions when applied. It's not the cleanest internal design in the long term but could get us most of the way with boolean stuff while maintaining backward compatibility (plus a long-term detail of not evaluating types away automatically, which is easy and would give us access to builtin contracts)

[yannham]

For the record, that's already how match statement works: they're a distinct node in the AST, considered as a value as well, but transparently act as functions when applied.

[suimong]

Just wondering, would a record contract count as a "contract coming from predicates"? It does not look particularly "boolish".

[yannham]

Yes, you're right. It is boolish if and only if all of the contracts affected to fields are. But sometimes we can also implement boolean operator (at least the or, the not is more constraining) even if the contracts aren't fully boolish. For example, for {foo | NonBoolish} \/ {bar | NonBoolish}, even if NonBoolish isn't a predicate, you can derive has_field "foo" as a discriminant that tells you directly which branch to take, and thus synthesize the or contract as: (I don't use has_field but pattern matching for clarity):

fun label =>
  match {
    value @ {foo, ..} => std.contract.apply {foo | NonBoolish} label value,
    value @ {bar, ..} => std.contract.apply {bar | NonBoolish} label value,
    _ => std.contract.blame label,
}

We discussed that in the meeting, and a special case for from_predicate (plus the little adaptation for types) is probably a good first step. Once those internals are implemented, we might think together of an interface for that - happy to ping you then @suimong if help is needed. Implementing at least an or on contracts, that is understood by the LSP is long overdue, so let's take the occasion to move that forward a bit.

[suimong]

Lovely!