How should match kinds be handled?

[jafingerhut]

Should match kinds be importable and treated as separate top level names?

For example, if one imported match_kind range from a namespace for the v1model architecture via import v1model as v1, should the P4 program be able to use v1.range as the match kind of a key in a table?

Right now this is the definition in core.p4 for exact, lpm, and ternary defined in the P4_16 language specification:

match_kind {
    exact,
    ternary,
    lpm
}

See https://github.com/p4lang/p4c/blob/main/p4include/core.p4#L72-L82 for the corresponding section of the core.p4 include file included with p4c.

The v1model.p4 include files extends that with a few more, like so (see https://github.com/p4lang/p4c/blob/main/p4include/core.p4#L72-L82):

match_kind {
    range,
    // Either an exact match, or a wildcard (matching any value).
    optional,
    // Used for implementing dynamic_action_selection
    selector
}

And the psa.p4 include file has a similar definition.

[mihaibudiu]

The question is whether v1.range and psa.range are the same thing or not. Note that we could create a crude namespace within match_kind by allowing dotted identifiers for match kinds too. This should be treated in the same way as error.

[jafingerhut]

I think that v1.range and psa.range are the same thing, but that is not because they have "range" in their name, but because people want them to work the same way in both architectures.

I doubt someone would want to import both v1model and psa into the same program, but if they did, v1.range and psa.range could both be used in your program, and they need not have the same definition. They might happen to have the same meaning, but that is entirely dependent upon how they should work.

Regarding creating a crude namespace within match_kind by allowing dotted identifiers, I would argue that we can do that with all names for every kind of thing today, and dispense with this namespace proposal altogether. That leads us into exactly the same problems we have today without this namespace proposal, and doesn't advance the language's features even a tiny bit.