Skip to content

LDWG meeting minutes, September 16, 2019

Jump to bottom
Nate Foster edited this page Sep 16, 2019 · 1 revision

Attendees

  • Mihai Budiu (VMware)
  • Calin Cascaval (Barefoot)
  • Chris Dodd (Barefoot)
  • Andy Fingerhut (Cisco)
  • Nate Foster (Cornell)
  • Vladimir Gurevich (Barefoot)
  • Jed Liu (Barefoot)

Status

  • We will finalize features for the v1.2.0 release.

String Types

Summary

  • This proposal seeks to add a string type to the language

References

Status

  • This was discussed at the August '19 meeting. Since then, @mbudiu-vmw wrote a pull request on the language specification.

Discussion

  • The restrictions on values of type string are designed to ensure that a data plane need not implement strings.

Action Item

  • We agreed to merge this after responding to reviewer comments.

  • People should chime in on the proposed implementation in p4c#2010

Automatic Converstions for Enumerated Types

Summary

  • The proposal seeks to allow automatic conversations to/from serializable enums.

References

Status

  • This was discussed at the August '19 meeting. Since then, @vgurevich wrote a pull request on the language specification and @jnfoster discussed with the API WG co-chair, who confirmed this will not affect them in an adverse way.

Discussion

  • Should the specification contain text about warnings for cases where multiple conversions would be needed?

  • The group thought that casts from numeric values to serializable enums should require a cast.

Action Item

  • We agreed to merge this after responding to reviewer comments about the language specification -- in particular, to be less prescriptive about warnings.

Structure Initializer Expressions

Summary

  • This proposal adds syntax for structure initializers.

References

Status

  • This was discussed at several previous LDWG meetings. Since then, @vgurevich developed a pull request on the language specification.

Discussion

  • Must all values be specified? Yes, for now.

  • We narrowed the proposal to eliminate the production that has a type name.

Action Item

  • We agreed to merge this after responding to reviewer comments.

Default Initializers

Summary

  • This proposal adds the ability to omit some fields in structure initializers

References

Status

  • This was discussed at several previous LDWG meetings.

Discussion

  • If we add this feature, it would be nice to bundle this with #717.

  • What is the syntax, if any, for omitting some fields?

  • What do we do with not-obviously-numeric values (e.g., header types, header union types, enumerated types, etc.)

  • For example, we could initialize the header to invalid, unless one of its fields is specified?

  • Note that since we allow empty header types, we would be changing the semantics of the following program

header h_t { }
h_t h;
h = {}; // currently valid, per Section 8.14, would become invalid

  • @mbudiu-vmw suggests that we should have explicit syntax for eliding fields.

  • @liujed expressed a desire for explicit syntax.

  • A simple (non-serialized) enum does not have a "zero." But the first field could be the default value.

Action Item

  • We agree this is a good feature to have, and it would be good to bundle with #717.

  • @vgurevich will create a pull request that explains what is the default value of each type, and what syntax will be used to elide fields?

  • We won't hold up v1.2.0 for this feature, but are open to including it if consensus can be reached electronically.

Add support for Table Apply Miss

Summary

  • This proposal adds support for t.apply().miss as an expression, where t is a table.

References

Status

  • @vgurevich produced a pull request that was approved by some LDWG members.

Discussion

  • What about miss vs. miss()? That's a separate issue.

Action Item

  • We agreed to merge this.

Naming Consistency

Summary

  • This proposal seeks to make P4_16's syntax more consistent

References

Status

  • @vgurevich has identified a number of issues

Discussion

  • If we rationalize the syntax, we will have to break some existing programs

  • Maybe we can support both for a while, and deprecate

Action Item

  • We will continue studying this issue, but will not take it in v1.2.0. @vgurevich will add this to the LDWG list of issues in the Wiki.

Semantics of Directionless Parameters

Summary

  • This issue raised by @jafingerhut illustrates a bug in the compiler related to the semantics of directionless parameters.

References

Status

  • The current compiler uses inlining, which is wrong for programs like the one linked to in the above issue.

Discussion

  • We discussed several possible language restrictions and implementation strategies.

Action Items

  • Fix the compiler so this program produces an error rather than incorrect code

  • Add a note to the compiler release notes

  • Continue to discuss

Next meeting

  • October 7th
Clone this wiki locally