Inconsistent error terminology for record-annotation mismatches

[blerner]

Consider a simple program:

type Point2D = { px :: Number, py :: Number }

fun next-pos(p :: Point2D) -> Point2D:
  { px : p.x + 1 }
end

Then consider two bad uses of that function, and the errors we get on the command line or in CPO:

• next-pos(3)

  The run ended in error:
  Expected to get `Object` because of the annotation at file:///home/blerner/pyret-lang/temp.arr:12:18-12:25 but got: 3
  Pyret stack:
  file:///home/blerner/pyret-lang/temp.arr: line 16, column 0

  

• next-pos({ x: 3, y: 5})

  
  The run ended in error:
  The record annotation at file:///home/blerner/pyret-lang/temp.arr:12:18-12:25 failed on this value:
  {x: 3, y: 5}
  Because:

• Missing field pxis required at file:///home/blerner/pyret-lang/temp.arr:10:17-10:29

• Missing field pyis required at file:///home/blerner/pyret-lang/temp.arr:10:31-10:43 Pyret stack: file:///home/blerner/pyret-lang/temp.arr: line 16, column 0

  
  ![image](https://github.com/brownplt/pyret-lang/assets/918464/7e64157a-13ae-4864-ae48-842e29a932ae)

Questions:

1. Do we want the terminology to be "record" or "Object"?
2. We can't fix things at the command-line, since we don't have the render-fancy-reason available there. But is it worth trying to special-case this error message and see if we can't get it to show "The Point2D annotation was not satisfied..."? (I can get this to work when Point2D is defined in the same file as it's being used, but I can't seem to get my localhost instance to read a shared gdrive file, so I can't test yet whether it works across files...which is where it's most useful.)

[blerner]

(@jpolitz , @shriram , would like your input here if you have time)

[blerner]

@jpolitz here's a thought to fix question 2 above:

1. Decorate PRecordAnn in runtime.js with an optional name field (and ditto PTupleAnn)
2. In PRecordAnn.prototype.check, if there is a name field then use it, else use "record" (or "Object", whatever we decide)
3. In anf-loop-compiler, augment compile-ann to take in a Option<String> name, that we can supply in a-type-let definitions (possibly some other analogous locations) and leave out in other situations.

The idea being, we'd wind up compiling type Point2D = {px:: Number, py:: Number} as

var Point2D## = R.mRA([ "px", "py" ],
                    [ L[7], L[8] ],
                    { "px": $type$Number1, "py": $type$Number1 },
                    "Point2D"
);

so that when it's used in an annotation-checking position, the runtime can say "oh, I'm a named annotation, I can give a better error message here".

I think this approach will work across modules and not require AST access (i.e. it'll work at the command line). The only downside I can think of is that if a type is aliased when imported or exported, the error message will be in terms of the original defining name.

I've just pushed an implementation of this idea to the PR above, so we can try it out.