Add Null Type to Mixer ValueTypes

[mandarjog]

Most other attribute processing frameworks have a notion of NULL type. We do not have this in Istio.

This will bring Istio attributes inline with other internal efforts.

[geeknoid]

We should consider this in the broader context of CEL and how we handle nil/null values in general.

[wora]

Do we still consider to use CEL since it is open sourced now?

[geeknoid]

Yes, Oz is tracking CEL evolution for us and we hope to converge.

…

On Wed, Jan 10, 2018 at 9:26 PM, Hong Zhang ***@***.***> wrote: Do we still consider to use CEL since it is open sourced now? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVucHbZVBXB0rR3pPR86FMDSMH0-QYtGks5tJZt7gaJpZM4NXQ-Z> .

[kyessenov]

https://github.com/google/cel-spec/blob/master/doc/langdef.md is the spec for reference.
I immediately noticed that the last change about short-circuiting && and || violates the spec.

[ozevren]

Not sure what you mean by that?

…

On Wed, Jan 10, 2018 at 9:30 PM, Kuat ***@***.***> wrote: https://github.com/google/cel-spec/blob/master/doc/langdef.md is the spec for reference. I immediately noticed that the last change about short-circuiting && and || violates the spec. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQR8IyfpjRqUS7pk09NHGppXfL9rGxamks5tJZxpgaJpZM4NXQ-Z> .

[ozevren]

Ah, you mean the commutative property, I presume.

…

On Wed, Jan 10, 2018 at 9:37 PM, Oz Evren ***@***.***> wrote: Not sure what you mean by that? On Wed, Jan 10, 2018 at 9:30 PM, Kuat ***@***.***> wrote: > https://github.com/google/cel-spec/blob/master/doc/langdef.md is the > spec for reference. > I immediately noticed that the last change about short-circuiting && and > || violates the spec. > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#98 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AQR8IyfpjRqUS7pk09NHGppXfL9rGxamks5tJZxpgaJpZM4NXQ-Z> > . >

[kyessenov]

Yes, 1/0 || true should evaluate to true.

[ozevren]

Also I assume you mean my latest PR as violation of this? If so, yes, that is the case. The current state of the expression language has some known gaps with CEL. That PR was mainly to fix an issue with the current expected behavior of the expression language, and was not about aligning with CEL. Aligning with CEL will require breaking changes compared to the current expression language behavior. That is a separate, large chunk of work.

…

On Wed, Jan 10, 2018 at 9:42 PM, Kuat ***@***.***> wrote: Yes, 1/0 || true should evaluate to true. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQR8I8MbiEKdobFe8cWcPkvPv9DZ2j_Jks5tJZ89gaJpZM4NXQ-Z> .

[kyessenov]

Right, I was just observing the differences. Doing a breaking language change is going to be difficult after 1.0. Maybe we should drive the language in the right direction gradually (by changing expectations).

[ozevren]

Right. That is what I started working on initially,, and have a Go based CEL parser & type-checker implementation waiting to go to the open-source world, with the idea that we can start with changing the parser front-end first (which would have given us some goodies such as ternary expressions). Unfortunately, that was placed onto the back-burner as we started doing more productionization work and as some of the CEL semantics was also still being solidifed. Still, I was able to sneak in some regular expression methods that aligns well with CEL: https://istio.io/docs/reference/config/mixer/expression-language.html. Hopefully, we'll be able to refocus on this soon.If you have any particular low-hanging fruits in mind that you think can be helpful, I'd be happy to discuss and see if I can sneak them in as well.

…

On Wed, Jan 10, 2018 at 9:51 PM, Kuat ***@***.***> wrote: Right, I was just observing the differences. Doing a breaking language change is going to be difficult after 1.0. Maybe we should drive the language in the right direction gradually (by changing expectations). — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQR8I-BU4pNORtz70avxDauP8HGlqOHhks5tJaFpgaJpZM4NXQ-Z> .

[kyessenov]

I would love to get error semantics aligned. I think the surface syntax change is not as hard on users as semantics change, and probably can be automated. We should use errors for missing fields and missing keys like in CEL, and also use JS-like e.f == e["f"] permutation.

Another useful thing is to introduce map and array literals, so that later, we can use data imports into policies.