On Tue, Nov 10, 2015 at 12:32 PM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Mon, Nov 9, 2015 at 11:40 PM, Martin Bjorklund <[email protected]> > wrote: > > > > > Andy Bierman <[email protected]> wrote: > > > > On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklund <[email protected]> > wrote: > > > > > > > > > Andy Bierman <[email protected]> wrote: > > > > > > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I implemented most of the 1.1 features that affect the > compiler in > > > > > > > pyang on the flight back from Yokohama. (if you have 1.1 > modules, > > > I'd > > > > > > > appreciate if you could try it out). > > > > > > > > > > > > > > In doing this, I realized that I forgot one part of Y10 - > "allow > > > > > > > restrictions on enumerations". If we allow: > > > > > > > > > > > > > > typedef foo2 { > > > > > > > type enumeration { > > > > > > > enum a; > > > > > > > enum b; > > > > > > > } > > > > > > > } > > > > > > > typedef bar2 { > > > > > > > type foo2 { > > > > > > > enum a; > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > we should also allow: > > > > > > > > > > > > > > typedef foo2 { > > > > > > > type bits { > > > > > > > bit a; > > > > > > > bit b; > > > > > > > } > > > > > > > } > > > > > > > typedef bar2 { > > > > > > > type foo2 { > > > > > > > bit a; > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > It is briefly mentioned in the description of Y10. > > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > Yet more complexity without any real use-cases? > > > > > > > > > > It is a matter of removing CLRs and inconsistencies. > > > > > > > > > > > How does auto-numbering work in both cases? > > > > > > > > > > > > > > > > > > typedef foo2 { > > > > > > type enumeration { > > > > > > enum a; > > > > > > enum b; > > > > > > } > > > > > > } > > > > > > > > > > > > typedef foo3 { > > > > > > type foo2 { > > > > > > enum b; > > > > > > } > > > > > > } > > > > > > > > > > > > typedef bar1 { > > > > > > type enumeration { > > > > > > enum b; > > > > > > } > > > > > > } > > > > > > > > > > > > > > > > > > What is the auto-numbering of enum 'b' in type foo3? > > > > > > > > > > There is none. The text says: > > > > > > > > > > When an existing enumeration type is restricted, the "value" > > > > > statement MUST either have the same value as in the base type or > not > > > > > be present, in which case the value is the same as in the base > type. > > > > > > > > > > > > > > > > > > good > > > > > > > > Is the refinement allowed to add, remove, or change if-feature-stmts? > > > > I don't remember seeing any text on that. > > > > > > The refine statement cannot address individual enums/bits (it can only > > > address structure) so the answer is that it is not possible to change > > > if-feature on enums/bits in refinements. > > > > > > > > > > It looks like it is -- > > > > > > 9.6.3. Restrictions > > > > An enumeration can be restricted with the "enum" (Section 9.6.4) > > statement. > > Aha, ok, I thought you meant the "refine" statement. > > Since it is ok to add if-feature to a node when a grouoing is used > (with "refine"), I think it should be ok to add "if-feature" to an > enum/bit when the type is restricted. > > > +--------------+---------+-------------+ > > | substatement | section | cardinality | > > +--------------+---------+-------------+ > > | description | 7.21.3 | 0..1 | > > | if-feature | 7.20.2 | 0..n | > > | reference | 7.21.4 | 0..1 | > > | status | 7.21.2 | 0..1 | > > | value | 9.6.4.2 | 0..1 | > > +--------------+---------+-------------+ > > > > > > Sec 9.6.3 says any sub-statement of enum-stmt is allowed > > > > All of the derived sub-statements from the refined enum are brought over > I > > asume > > > > typedef foo4 { > > enumeration { > > enum A1 { > > if-feature foo; > > } > > enum A2; > > } > > } > > > > typedef foo5 { > > type foo4 { > > enum A1; > > } > > } > > > > Is enum A1 conditional on the foo feature in both foo4 and foo5 typedefs? > > Yes. > > > typedef foo6 { > > type foo4 { > > enum A2 { > > if-feature bar; > > } > > } > > > > According to the spec, adding if-feature in foo6 is also allowed. > > Yes. > > > > > typedef foo7 { > > type foo4 { > > enum A1 { > > if-feature bar; > > } > > } > > > > Is the A1 enum in foo7 conditional on feature foo and bar, or just bar? > > Both IMO - again compare w/ nodes in groupings. > > > We probably need text to clarify these situations. > > Yes -- it is OK to make a node more conditional but not less conditional. You cannot take away an if-feature that is defined in the original typedef. This is easier to say than to enforce since if-feature syntax has been expanded. typedef foo8 { type foo4 { enum A1 { if-feature "bar and not foo"; } } } Is foo8 an error? IMO, no. It can be very difficult to detect conflicts. It is easy to just apply all the logic, which may produce an expression that is always false. > > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
