Subject: [netmod] Y32: allow boolean combinations of patter

From: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Apr 2014 10:36:10 +0200 (CEST)

Hi,

My first reaction to this proposal is that it seems a bit
complex.  I can see the theoretical problem, but I have never seen
this in a real module.  In most cases, this can be solved with the
current mechanism.  For example:

   (p1 | p2) & p3

can be solved by:

  pattern "p1 | p2";
  pattern "p3";

  p1 | (p2 & p3) is trickier.

So I am not sure the additional complexity is worth it.

/martin

---

From: Per Hedeland <[email-masked]>
Date: Fri, 04 Apr 2014 11:13:55 +0200

> current mechanism.  For example:

+1 (obviously:-)

>   p1 | (p2 & p3) is trickier.

Well, you can do it with a union:

   type union {
     type string {
       pattern p1;
     }
     type string {
       pattern p2;
       pattern p3;
     }
   }

More readable than the suggested solution IMHO.

> So I am not sure the additional complexity is worth it.

+1. In general, it may have been mentioned on the list, but don't we
have more restrictions than "must not break 1.0 modules" for 1.1?
Something like "only include changes that are necessary to solve
problems encountered in actual usage experience, not those that are only
nice-to-haves". The amount of effort required for implementors to add a
lot of new but not-really-necessary features should not be ignored I
think, since it could have a negative impact on the acceptance of YANG
in general.

--Per

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2014 11:26:30 +0200

> think, since it could have a negative impact on the acceptance of YANG

The process is that the WG needs to reach concensus for each submitted
issue whether it is appropriate to address it (this is when an issue
moves from NEW to OPEN). I trust WG members that they will take into
account the cost / benefit tradeoffs in their judgements.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Apr 2014 11:52:55 +0200

> Well, you can do it with a union:

Or also simply as (p1 | p2) & (p1 | p3).

It might be helpful though to be able to define pattern variables because quite often the same fragments have to be repeated. Consider this alternative definition of IPv4 address type:

typedef ipv4-address-no-zone {
  type string {
    let octet {
      pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
    }
    pattern '($(octet)\.){3}$(octet)'
  }

This would be IMO a very useful aid for readers.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 03:12:02 -0700

On Fri, Apr 4, 2014 at 2:52 AM, Ladislav Lhotka <[email-masked]> wrote:

> It might be helpful though to be able to define pattern variables because
> quite often the same fragments have to be repeated. Consider this
> alternative definition of IPv4 address type:
>

IMO we have plenty of esoteric syntax already.
The pattern-stmt does not need expandable variables.
The description-stmt should explain the intent, so
the pattern does not need to be that human-readable.

Lada

Andy

---

From: Per Hedeland <[email-masked]>
Date: Fri, 04 Apr 2014 13:23:35 +0200

> Or also simply as (p1 | p2) & (p1 | p3).

You're changing the requirements, that's cheating.:-) And besides being
more cumbersome to write and read (prompting your other suggestion), it
may also have a significant impact on the performance of verification.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Apr 2014 13:32:02 +0200

> You're changing the requirements, that's cheating.:-) And besides being

How do I change anything? It is possible even now:

pattern "p1|p2";
pattern "p1|p3";

(of yourse, p1 has to by literally copied).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 04:35:27 -0700

> >> Well, you can do it with a union:

IMO this union type is more readable.

> may also have a significant impact on the performance of verification.
We have to make sure that YANG 1.0 modules still compile, so any
proposal that doesn't do that should be immediately rejected.

If there are already ways in YANG to solve the problem, then there
should be strong consensus that the current mechanisms are too hard
to use, or else reject the proposal.

Andy

---

From: Per Hedeland <[email-masked]>
Date: Fri, 04 Apr 2014 13:46:58 +0200

> How do I change anything? It is possible even now:

Yes of course. The requirement was to express p1 | (p2 & p3), you're
changing it to express (p1 | p2) & (p1 | p3) - obviously the semantics
are the same, but it is not what was asked for.

> (of yourse, p1 has to by literally copied).

Exactly. And the implementation (unless it employs some rather advanced
- and probably unlikely to be implemented - optimization techniques)
will need to do the match-check for p1 twice instead of once.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Apr 2014 13:52:56 +0200

> IMO this union type is more readable.

On the other hand, it can be difficult to determine which of the union cases actually applies.

> proposal that doesn't do that should be immediately rejected.

OK, the ‘patterns’ container isn’t needed, and without it this requirement is satisfied. 

> to use, or else reject the proposal.

You often emphasize the sequence of priorities: module readers, then module writers, and then software tools. It is the case here: with pattern variables some awkward patterns would be much easier to understand, and writers would be less likely to make a typo.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Apr 2014 14:06:07 +0200

> will need to do the match-check for p1 twice instead of once.

If the patterns were defined using variables so that it is clear that p1 is the same in both patterns, then such an optimization wouldn’t be rocket science. And one could also optimize parsing of IP addresses because then it is immediately clear that only one DFA is needed for parsing “octet”.

Lada