Clarify how self_eval_int_negative_min test will be passed about cel-spec HOT 7 CLOSED

Good question, -9223372036854775808 is the minimum value for an int64 and is parsed as such, so the negation operator (-_) isn't actually applied in this case.

That said, you've raised a good test case for double negation: -(-9223372036854775808) should produce an error and it likely doesn't in the implementations.

@JimLarson thoughts?

from cel-spec.

The definition of numeric values says.

“ We only support positive, decimal integer literals; negative integers are produced by the unary negation operator.”

This seems to suggest the test case is at odds with the specification.

from cel-spec.

from cel-spec.

Will that lead to changes in the grammar to prefix an optional leading ‘-‘ to the numeric tokens to created signed tokens?

from cel-spec.

In the current implementations, the numeric tokens are signed. I believe they have been for quite some time:

google/cel-go#109

It appears that I forgot to update the lexis in the spec, but you can see from the grammar change about 1.5 years ago, that the tokens are signed and the spec out of date.

Out of curiosity, are you looking to implement the spec yourself with a custom lexer / parser?

from cel-spec.

My mistake. I was relying on the EBNF in the language specification document. As well as the text of the specification. Should I put in a PR to fix that?

I see how signs were added to the literal specification in https://github.com/google/cel-go/blob/master/parser/gen/CEL.g4#L80-L89.

And yes. We're looking at creating a CEL implementation. cloud-custodian/cloud-custodian#5759.

from cel-spec.

I'd be happy to accept a PR. Honestly, this was my oversight, so I wouldn't have expected anyone to dig into the implementations to figure this out.

If you're looking to bootstrap your project, you could also use the ANTLR Python codegen / runtime. You will likely be able to build something faster with another tool, but the ANTLR stack should be self-consistent.

You don't need to support proto-based types, a pure-Python representation of CEL values should be sufficient, though it would be a good idea to support nullable primatives and the strict definition of JSON that proto does. Also an ability to map from the CEL AST proto to your in-memory representation will make it possible to setup a conformance harness.

I have more advice that I'd be happy to give, if you'd like to reach out via the [email protected] mailing list.

Cheers!

from cel-spec.