Using the contract annotation to perform mappings of record fields

[DrRuhe]

While searching for a way to ergonomically update only select (nested) fields of a record, I found out, that contract annotations are able to change the values of fields in contracts, leading to this code:

let contract_update = fun updater unused_label value => (updater value)
in
{
    a.b="foo",
} | {
    a.b | contract_update (fun oldvalue => "%{oldvalue}bar")
}

## Evaluates to:
{
  "a": {
    "b": "foobar"
  }
}

This seems a bit hacky to me but it works so I'm happy. Is this intended behavior / a known pattern?

[vkleen]

This is partly intended and partly an accident. For contracts to be properly lazy they need to be able to return a new value. For example, imagine having to check some condition on all the fields of a very large record. We don't want this check to evaluate the record fully, since that could take a very long time, but instead defer the actual check to the place a field in the record is used. For this, we make would make a new record whose field values are the original record's values wrapped in the check. There's a worked example in the manual.

The side effect of this design is that a contract can actually return arbitrary values, like you discovered. For a single contract application to a value that's not a big deal. But contracts attached to record fields are "sticky", the intention being that a contract attached to field encodes a property that this field must at all times satisfy, even after many merges. It can be very opaque when exactly such contracts end up being applied to a value. In particular, they can end up being applied multiple times. This means that you need to make sure that whatever the contract returns is also accepted as an input to the contract. That is, contracts should be idempotent to prevent surprises. You will typically see this most quickly when using record merging. Consider

let Update = fun label value => "bar"
in
let record =
  {
    foo = "foo"
  } | {
      foo | Update
    }
in
record & { foo | force = "not bar" }

You might reasonably expect this to evaluate to { foo = "not bar" }. But because the Update contract is sticky, it will be applied to the new value "not bar" of foo and promptly proceeds to replace it with "bar".

In summary, I don't recommend using the contract system in this way. A valid use case for the "mapping power" of contract could be a normalization step, like std.enum.TagOrString for example. But it requires a bit of care to make sure that your normalization contract doesn't turn into a hard to track down surprise.

[DrRuhe]

Is there currently an alternative to updating such a nested field with a function that gets the old value as a param? An earlier version I had was this:

 map_value = fun accessor updater record =>
            let accessor = accessor | String in
            let record = record | {_:_} in

            if (! std.record.has_field accessor record) then
                std.fail_with "The record to update does not contain the field '%{accessor}'"
            else
                let oldvalue = record."%{accessor}" in
                let newvalue = updater oldvalue in
                std.record.update accessor newvalue record

But this is unable to operate on nested fields, as an accessor String like "a.b" would literally map to a field "a.b" and would ignore a={b="foo",},

[vkleen]

I wrote a "remove record field by path" function here. That shouldn't be too hard to adapt, I think.