Constructor parameters are not explicitly listed as compile-time-known values

[vgurevich]

The full discussion can be found in https://github.com/p4lang/p4c/issues/2995

The Section 17.1 Compile-time known values omits constructor parameters from the list.

It is fairly clear from the other places in the spec that they should be there:

First, Section 6.7.1 says:

All constructor parameters are evaluated at compilation-time, and in consequence they must all be directionless (they cannot be in, out, or inout); this applies to package, control, parser, and extern objects. Values for these parameters must be specified at compile-time, and must evaluate to compile-time known values. See Section 14 for further details.

Section 14 says this, indeed:

Constructor parameters must be directionless (i.e., they cannot be in, out, or inout) and when the parser is instantiated, it must be possible to fully evaluate the expressions supplied for these parameters at compilation time.

So, it's pretty clear that the contructor parameters are compile-time known values.

[vgurevich]

Good discussion happened on the corresponding pull request (https://github.com/p4lang/p4-spec/pull/1002) and the reference to the issue #932 has been made.

I understand the arguments.

Practically speaking, there are the following problems:

1. If we literally interpret the spec the way it is written today, the following things that are very common in coding practice will be simply outlawed, specifically: 1.a. The ability to use constructor parameters to instantiate nested parsers/controls and externs (the spec requires constructor parameters to be compile-time known values) 1.b. The ability to use constructor parameters to specify table sizes (the spec requires those to be compile-time known values)
2. There is a distinct need to be able to create parsers/controls parameterized on the types. At the very minimum, one should be able to specify the width of a type like bit<X>. Currently, the only workaround is to use preprocessor, which is ugly.

One way or another we need to work on this. Perhaps, the same outcome can be achieved by allowing controls and parsers to have type parameters, but I am afraid that in any case we'll have to do type checking recursively.

[QinshiWang]

An earlier issue: https://github.com/verified-network-toolchain/petr4/issues/218.

[QinshiWang]

@vgurevich That's also the reason that I think this is useful. Not only for control and parsers, functions that are parameterized on width are also useful.

[QinshiWang]

For the convenience of tracking, I also link this issue [#932] here (already mentioned in the PR).

[apinski-cavium]

To me constructor parameters are like non-type template arguments in C++ and such.

Maybe the thing to do is change all compile time know values to constant expressions instead and apply similar rules as C++. This does require extra work and would fix/improve https://github.com/p4lang/p4-spec/issues/932#issuecomment-1114059234 and even https://github.com/p4lang/p4-spec/issues/1057 .

[mihaibudiu]

Is what is left of this really a duplicate of #932? Then maybe we can close this and solve (or not) #932.

[jnfoster]

Closing in favor of #1213.