Fix polarity for polymorphic contract failure

[ebresafegaga]

Closes #821

[yannham]

The polarity isn't always positive:

let evaluate_incr_at_1 : (forall a. (a -> a) -> a -> a) -> Num = fun ev =>
  ev ((+) 1) 1 in
evaluate_incr_at_1 (fun f x => null)

This should blame the caller, not evaluate_incr_at_1. The point is, the polarity is not the one of the occurrence of the type variable, but is the polarity of the introducing forall _.

[yannham]

LGTM. Because the logic is not obvious, a little comment in the code could help our decedent (important information: we set the polarity of the label to lPol because this is what's important for blaming polymorphic contracts).

In the future it could be nice to have an even more specialized error message. But that can come in a later PR. In general I've been thinking lately about enriching the interface of label in the Nickel language itself, so that custom contracts can set "notes" and additional messages by themselves, instead on relying only on the erase-on-write msg field

[ebresafegaga]

In general I've been thinking lately about enriching the interface of label in the Nickel language itself, so that custom contracts can set "notes" and additional messages by themselves, instead on relying only on the erase-on-write msg field

Interesting. This would probably require adding a new operator to set the "notes" field.

[yannham]

Interesting. This would probably require adding a new operator to set the "notes" field.

Yes. Maybe at some point it would be easier to make it an actual Nickel record, so that you can at least set polarity, message and other basic things directly using record.replace or merging. You would probably still need opaque types and dedicated primops for other things like the type path, but that could already be an improvement.