Currently, pattern pages are defined like this:

{
  "type": "hexcasting:pattern",
  "op_id": "hexcasting:get_caster",
  "anchor": "hexcasting:get_caster",
  "input": "",
  "output": "entity | null",
  "text": "hexcasting.page.basics_pattern.get_caster"
}

This is bad for a few reasons:

• Not localized, so every language gets en_us i/o in the book:
  
• Not standardized, so even within Hex itself, the same types etc. are written in several different ways:
  
  
  

I'm thinking something more like this:

  "input": [
    "hexcasting:number",
    {
      "type": "hexcasting:or",
      "values": [
        "hexcasting:number",
        "hexcasting:vector"
      ]
    },
    {
      "type": "hexcasting:list",
      "value": "hexcasting:entity"
    }
  ],

num, (num | vec), [entity] ->

This would enforce standardization, allow localization, and make arguments far more machine-parsable, which would be great for tools like hexdoc, HexBug, and Hex Studio.

I set this as medium priority because if we implement it, it'll be a breaking change, so we should do this before releasing 0.11 if we do it at all.
(see below)

More examples:

• Union: vector | null, vector|null, vector or null
• Number: number, num
• Vector: vector, vec
• List: list, [pattern], list of patterns

I don't think this needs to be a breaking change, actually. We could always just continue to accept the current raw string format.

Also, this should wait until Sam and Alwinfy's JIT feature, and/or my type checker, as both may make this issue irrelevant.