-
Notifications
You must be signed in to change notification settings - Fork 80
LDWG Meeting Minutes: May 7, 2018
Meeting organized at Cisco in Milpitas; host is Andy Fingerhut
Participants
- Andy Fingerhut
- Han Wang
- Andy Keep
- Chris Sommers
- Calin Cascaval
- James Coole
- Gordon Brebner
- Milad Sharif
- Mihai Budiu
- Remove "globalname" annotation from spec (https://github.com/p4lang/p4-spec/pull/613)
We agreed to merge this PR.
- Small grammar change (https://github.com/p4lang/p4-spec/pull/608)
We agreed to merge this PR.
- P4 table size property (https://github.com/p4lang/p4-spec/pull/603)
This PR has already been merged.
- Serializable enums (https://github.com/p4lang/p4-spec/pull/615)
Andy Keep discusses The enum is really a hidden bit<> (or int<>) type. Operations are !=, assignment, cast to/from. Should we allow aliasing of symbolic names? Andy will refine the pull request.
- Parser value sets (https://github.com/p4lang/p4-spec/pull/602)
Han: should allow users to specify names for the fields in the set --- this has recently been merged in the compiler by allowing a struct as a value_set type parameter AndyF: one instance of value set should be usable in multiple parser match statements Han: Annotations on struct fields can be used to indicate match kind in the implementation.
We agreed to merge this PR.
- newtype/control-plane types (https://github.com/p4lang/p4c/pull/1244)
This feature was needed to be able to generate the control-plane API. Annotations on types will work better, if they are needed at all.
This half-implemented in the compiler. Mihai should write the spec to describe this feature and submit a PR.
Q: Should we inherit operations?
Q: Should this work for structs, tuples, etc.
Andy: volunteer to write up what operator inheritance to be allowed.
Calin: proposed to rename the operation from "newtype" to simply "type".
Q: We are polluting the language namespace with new global identifiers, which could cause old programs to break. We can attempt to fix this by having a better grammar, and not reserving these identifiers as keywords.
- documentation through comments and annotations (https://github.com/p4lang/p4-spec/issues/580)
- support key-value pairs in annotations (https://github.com/p4lang/p4-spec/issues/605)
Chris Sommers will write the spec for k=v annotations; it should include an example
How should we handle comments? What is the exact comment syntax supported? We will investigate when a clear need appears; it should be based on Doxygen and JavaDoc, but probably not support all features.
- type 'int' (https://github.com/p4lang/p4c/issues/1040)
Who needs it? Do we need it for PSA? Milad think so. Milad will write the spec to add the 'int' type. The asymmetry between bit<>/bit and int<>/int is probably not a big concern.
- conditional execution in actions (https://github.com/p4lang/p4c/issues/644)
Is this a front-end or back-end issue? Does the spec allow control-flow in actions? Andy: the language should allow control-flow in actions. Han: the spec should be updated if we want this feature.
- expressions in bit<*> size (https://github.com/p4lang/p4c/issues/47)
One possibility: only allow parantheses if an expression is used. Calin: How should the spec be written? without without parentheses? We should try to write the most user-friendly spec.
- Named arguments (parameter with default values, optional parameters) (https://github.com/p4lang/p4-spec/pull/599)
does this proposal solve all the problems? Special values: NONE vs Null vs default value. None (@optional) = specified by architecture document. Default values can only be a compile-time constant and in arguments. Should see if the PSA could be done cleaner using these tools. Calin: will rewrite PSA. Mihai: will work on the implementation; only about 1/3 done (new syntax accepted).
- P4 modularity constructs?
Postponed a discussion for later.
Plan to meet on May 21 - last meeting before the workshop.