New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tuples: no elimination form #864
Comments
Yes, I was planning to propose tuple field access to the spec, should be very easy to implement. |
I approve, but let's discuss this at the next LDWG meeting before merging. |
@jnfoster -- I just wanted to comment on the statement that you do not like structs as ordered collections. There are several places, most notable being the In fact, I stopped using the term "unordered collection" in my training materials. This was true about the What do you think? |
I was surprised when you mentioned |
if you can have structs in headers this seems quite consistent. |
Headers can contain structs: this is from the spec: where each typeRef is restricted to a bit-string type (fixed or variable), a fixed-width signed integer type, a boolean type, or a struct that itself contains other struct fields, nested arbitrarily, as long as all of the “leaf” types are bit, int, a serializable enum, or a bool. |
I agree the spec says you can have structs in headers. What is slightly surprising to me here is that |
lookahead needs to usually just look at a header fragment (prefix). |
@mbudiu-vmw -- there are actually a lot of reasons for the code I mentioned in #879. This is how you would typically get user-defined fields in and this generally has to be metadata, so that you do not have to worry about the validity (plus there are a number of other things at play if you consider the fact that you might get only part of the packet in). This is a useful construct that we support today, so I think we should have it. |
Why not use array indexing syntax? Currently, we have Edit: looks like there has been discussion about this in the PR: #877. |
Personnel
Design
Implementation
p4-spec
: Tuple fields #877p4c
: Tuple field access using array index operator p4c#2655 this implementation names fields f[0], f[1].Old version: Tuple elim p4c#2451 this implementation names fields f0, f1, f2.
Process
p4-spec
p4c
Frank Pfenning from CMU is one of the world's experts on type systems. He has a set of beautiful design principles that provide guidance when developing new type systems. One of these principles, called harmony, governs how the introduction forms and elimination forms for a type interact. An introduction form is an expression that lets you create a value of a given type. An elimination form is an expression that lets you destruct or access the components of a value of a given type.
Unfortunately, unless I missed it, when we added tuples to the language, we forgot to add any elimination forms. So if you create a tuple, you no longer have a way to access its components. (The one exception is in parsers, where a
select
can be used to destruct a tuple and match it against one or more key sets; but this can't be done in controls.)To fix this, I think we need to add one of the following to the langauge:
switch
to support pattern matching on tuples (a great option; already discussed as a possible language extension in an appendix).(H/T to the Neptune team at @cornell-netlab who figured this out: @piercedouglis, @minmit, @rachitnigam)
The text was updated successfully, but these errors were encountered: