Named Record Types

I work with a lot of objects, it’d be helpful to tag them with a name. It’d make for more terse signatures.

I still think we should show the complete interface if a type error occurs though. But when rendering the signature, it’d be preferable to just use the name, I’m finding type errors nearly always wrap the terminal/repl because I’m working with large records.

Then the ^^^^ don’t line up with the particular argument, so its not immediately obvious what is causing it to fail.

[davidchambers]

Good idea.

An idea that just occurred to me is to have the representation span multiply lines:

{
  bar :: Array String
  baz :: {
    quux :: Integer
            ^^^^^^^
               1
  }
  foo :: Boolean
}

As opposed to:

{ bar :: Array String, baz :: { quux :: Integer }, foo :: Boolean }
                                        ^^^^^^^
                                           1

We could use the name of the record type in the signature, then expand the type in the description below and underline the invalid portion.

[JAForbes]

Some new thoughts:

I’m using this to validate API responses and there are a lot of fields, sometimes its hard to see what is wrong with a value when there are 50 keys with various levels of nesting.

It’s not that useful to render the complete type for large objects (say keys > 5, or levels of nesting greater than 2). It’d be a lot more useful to me to list the paths and types that were invalid, with the expected type and the actual value. Particularly when there are multiple validation issues.

TypeError ... yada

1. Value -123 at path: a.b.c.d is not a member of PositiveNumber
2. Value [1,2,3] at path: a.b.c.e is not a member of List String

It could also be handy to show the values in context, with the valid values filtered out.

TypeError Provided value did not satisfy custom RecordType API Response

The provided value did not satisfy the following Type constraints:

Preview:

  { a: 
    { b: 
      { c: 
         { d: -123, e: [1,2,3] }, ... 
       }, ... 
     }, ... 
  } 

1. Value -123 at path: a.b.c.d is not a member of PositiveNumber
2. Value [1,2,3] at path: a.b.c.e is not a member of List String

It’d be great too if validate, or something similar could provide this metadata as an object of the form: { preview :: String, failures:: List { value:: Any, path: List String, type: Type } }

That way libraries like sum-type (and hopefully others) could build domain specific error messages without recreating a lot of what sanctuary-def already does very well.