Constraint that can select type definition based on field or annotation

[popematt]

For a federated data model, it can be cumbersome to maintain union types as the number of models grows and becomes further decentralized. Union types can also be expensive because of the O(n) evaluation.

For patterns such as the following, we could potentially bypass these challenges by using the relevant type information to look up the correct type.

// Type is annotated on struct
cat::{ name: "Edward", breed: "Himalayan", likes_catnip: true }

// Type is a field in the struct
{ __type:"dog", name:"Rufus", breed:"Welsh corgi" }

// Type is a field in a wrapper struct
{ $type: "fish", value: { name: "Sunny", species: "Carassius auratus" }

// Type is the symbol at the head of the s-expression
(gerbil "Bob")

Consider this strawman proposal. We could have a constraint such as lookup_type:

type::{
  name: list_of_pets,
  type: list,
  element: {
    lookup_type: from_annotation
  }
}

This constraint would cause the validator to inspect the specified location, get the type name, and locate the type, and then validate the element against that type. This is more efficient than something like the following

type::{
  name: list_of_pets,
  type: list,
  element: {
    one_of: [
      dog,
      cat, 
      fish, 
      gerbil, 
      rock,
      dragon, 
      // Potentially many more types
    ]
  }
}

Obviously there are a lot of details to be worked out, but I think the concept has some merit.

Some questions to consider:

• Should this be an extension of type, a separate constraint, or a new type of dynamic type reference? It could, perhaps, be useful to define something like one_of: [string, (dynamic_type_ref from_annotation)].
• If the type is not found, should that be a validation failure or should it fallback to use $any in place of an unfound type? (I.e. should the application be able to say "I only want to validate things I know about, and things that I don't know about should always pass validation.")
• Must the type already be imported? If not, how do we locate the type? If so, does that defeat the purpose of this constraint?