config.yml expanded for more attribute types

[enebo]

With the introduction of kind we get much better documentation and generation potential (I am using it as Java types already in loading) but for many node types we do not have a single kind. It would be nice if we could get a proper list of kinds that something can be.

Let's look at HashNode as an example:

  - name: HashNode
    child_nodes:
      - name: opening
        type: token?
      - name: elements
        type: node[]
      - name: closing
        type: token?
    comment: |

In elements we can have AssocNode and AssocSplatNode. It would be nice if we could add this knowledge to config.yml in some fashion. Some stream of consciousness ideas:

1. OR'd kind

  - name: HashNode
    child_nodes:
      - name: opening
        type: token?
      - name: elements
        type: node[]
        kind: AssocNode|AssocSplatNode
      - name: closing
        type: token?
    comment: |

2. kinds entries

  - name: HashNode
    child_nodes:
      - name: opening
        type: token?
      - name: elements
        type: node[]
        kind: Assocs!
      - name: closing
        type: token?
    comment: |

  ...

kinds:
  -name Assocs!
   kinds:
    - name: AssocNode
    - name: AssocSplatNode

The tension between having a simpler syntax 1) or a new section 2) would depend on whether we want more information or not associated with this info. For example, if we want to specify that both Assoc and AssocSplat have a common value attribute then
perhaps we can add that. This would allow the template generator to know it can perhaps make a common interface or generate common method:

kinds:
  -name Assocs!
   kinds:
    - name: AssocNode
    - name: AssocSplatNode
   attributes:
      interface: 
        -name: ValueNode
        -attribute: value

I spent maybe 10s thinking about actual syntax so do not take that seriously but the general goals would be:

1. More easily understand what kinds of nodes can be found in children (or just node when it is too large/everything).
2. Consider giving more knowledge about commonality between different nodes types when they are consumed in a particular context.

I am not trying to make a type system in YAML but right now I spend a lot of time running bin/parse on syntax to try and see what nodes are children of other nodes. The idea of generating subtypes or interface for related node types has some appeal (ConstantPathNode+ConstantReadNode comes to mind).

[eregon]

I think a way to declare a common (abstract) superclass or a set of interfaces/modules per Node type could be useful, and that could then be used for this.

[eregon]

It would be useful to find concrete examples where the superclass/interface is useful, I don't know how useful it would be in practice.

I like the | syntax because it's very simple and explicit, maybe better to start with that?

[enebo]

I think a way to declare a common (abstract) superclass or a set of interfaces/modules per Node type could be useful, and that could then be used for this.

I would like something which could be used to generate interfaces or a common base class but I also just want more info I can reference in config.yml. Reading this file has been really helpful (along with bin/parse) in figuring out what can do what.

[eregon]

(I am using it as Java types already in loading)

Sounds great, please cc me on the PR for that when you open it.

[enebo]

@eregon I have a playground branch on enebo/yarp. I will make sure I commit anything not committed yet :)