Checking records

[tweag]

Checking records

[thufschmitt]

Just a couple of side remarks:

• {a: Num, b: String, _ : Bool} isn't valid in Nix since records are always finite (unless _: Bool also allows the fields to be missing)

• You can also pattern match on optional fields like

  let f = { x ? 4 }: x+1; in
  f { x=5; } + f {}

  I guess the framework should handle these (which can be done fairly easily if you have the Δ contract, not sure otherwise)

[teofr]

since records are always finite (unless _: Bool also allows the fields to be missing)

Yeah, I'd say that _ : Bool allows the field to be missing. I guess the reason of saying _ : Bool U Δ is that the type information is forwarded, and you can force to use an or at the type level, right?

which can be done fairly easily if you have the Δ contract

That's true if you also have union types, we're putting that on standby for the moment being. So maybe having ? as a primitive

[thufschmitt]

I guess the reason of saying _ : Bool U Δ is that the type information is forwarded, and you can force to use an or at the type level, right?

Not sure I understand what you mean. The reason we had that is just that it made everything more consistent (because that way _ : A is just an shortcut for forall x. x: A), but since it can always be used when the type contains Δ it's also sensible to imply it.

That's true if you also have union types, we're putting that on standby for the moment being. So maybe having ? as a primitive

Oh yes, I didn't follow that part. Then yes, you probably need something like a x :? Bool construct to replace x : Bool \/ Δ

[teofr]

Regarding Flow

Flow is Facebook's answer to typing JS (the main difference with TypeScript is that is not a different language, and is designed to be used with JavaScript's code "out of the box", but I'm not an expert on either). They have Object type, which are more or less what we want.

They have a bunch of stuff that is of interest to us:

• Optional fields
• They have open and close records (unsealed and sealed) with regards to usability:
  • sealed know all of its fields, and every access is checked,
  • unsealed objects sometimes can check if an access is safe, but it's usually considered unsafe
• They also have a notion of exact objects, where only an object with exactly those fields matches. This is what we consider a close record.
• Lastly, there is an "indexer property", that is similar to the catch all idea presented above, it let's you use an object as a map/dictionary.

Main differences (or stuff we don't really care):

• Objects are modifiable

I think their development is quite similar to the idea of having a catch all case, and a special type stating that field doesn't exist. Their difference with unsealed and indexed objects is because Objects may grow and shrink during execution, I don't think we need to make this difference. I'll keep looking into their stuff, but this is just to have an idea of what a good set of capabilities might be, and there doesn't seem to be anything too different from the previous set of thoughts.

[yannham]

Closing old stale issue. Ideas mostly implemented (see #158).