Anonymous Records

[ChrisPenner]

Adds anonymous record types to Unison.

Anonymous records allow you to create types and values which work effectively liked named tuples.

E.g.

manhattanDistance : {x: Int, y: Int} -> {x: Int, y: Int} -> Nat
manhattanDistance = cases
  {x: x1, y: y1}, {x: x2, y: y2} -> let
    dx = abs (x1 - x2)
    dy = abs (y1 - y2)
    dx + dy

> manhattanDistance {x: +1, y: +2} {x: +3, y: +4}

You can also embed these types in other types as usual, e.g. you could instead define this using a Point type,
NOTE the difference between Unison's current ADT-based records type Point = {x: Int, y: Int}; and the new form: type Point = Point {x: Int, y: Int}.

The former is an ADT with two fields, and generated accessors. The latter is an ADT with a single field which is an anonymous record.

type Point = Point {x: Int, y: Int}

manhattanDistance : Point -> Point -> Nat
manhattanDistance = cases
  Point {x: x1, y: y1}, Point {x: x2, y: y2} -> let
    dx = abs (x1 - x2)
    dy = abs (y1 - y2)
    dx + dy

> manhattanDistance (Point {x: +1, y: +2}) (Point {x: +3, y: +4})

You can access record fields with rec@field (no spaces)

person = {address: {street: "123 Main St", city: "Anytown", state: "CA", zip: "12345"}}

> person@address@city
          ⧩
          "Anytown"

This is NOT a "Row Types" implementation, however it does include rudimentary sub-typing, i.e. you can type {name: Text | ... } to accept ANY record which has a text name field; however once the type information for the fields in ... is lost it cannot be recovered.

See the new-records.md transcript for a more comprehensive exploration.

[ChrisPenner]

I've had Claude finish of the remaining bits and bugs; I gave it a review, but it would definitely be prudent to leave it on trunk for a bit before we make a release with it, it's a huge change.

For clarity, the handwritten stuff is everything on cp/record-prototype-human, the ai stuff is everything since then (Claude labels its own commits)

[aryairani]

I wonder why libffi failure is only showing up now?

[aryairani]

I forget, was there some really good reason(s) not to overload . (namespace lookups, floats) for field accesses instead of overloading @ (bound patterns)

[pchiusano]

I forget, was there some really good reason(s) not to overload . (namespace lookups, floats) for field accesses instead of overloading @ (bound patterns)

Is Foo.bar a field accessor on the value Foo or a qualified name? No way to know at parse time.

Haskell sorta gets around this by not allowing uppercase identifiers other than types and data constructors, and requiring that data constructors and module names be uppercase.

So Foo.bar can't be a record access because that would imply Foo is a nullary data constructor, and nullary constructors don't have fields.

And foo.bar can't be a qualified name, because qualified names always start with an uppercase segment like List.map. So foo.bar has to be the expression foo . bar.

[ChrisPenner]

Yeah, pretty much all of what Paul just said, it would make a pretty big mess of the lexer, parser, and pretty-printer to use .
Also then we'd have to make sure it's always unambiguous, even though TDNR and record access are completely different operations; e.g. in rec -> rec.field; if your namespace has rec.field defined it's impossible to know what rec.field should refer to, and there's a bit of an explosion in things you need to check when you're doing nested access, e.g. is person.address.street an FQN, or is person.address an fqn and .street is record access? Or is person a record and .address.street the accessor?

The syntax is relatively easy to change to something else if we want, as long as that something else isn't . haha

[aryairani]

I approved it, we can always revisit syntax later. Go ahead and merge once CI is passing?