-
Notifications
You must be signed in to change notification settings - Fork 228
Rationale
CEL is meant for safe evaluation of code from untrusted sources, with a minimum of mechanism. Think of a desktop calculator, not a virtual machine.
Wherever possible, CEL attempts to emulate the syntax and semantics of widespread programming languages. In particular, we will follow Google's ZetaSQL language whenever possible.
Within the constraint of familiarity, the feature set of the language is reduced to the bare minimum.
CEL has a simple but abstract definition that allows multiple evaluation strategies. In particular:
- Lazy evaluation to execute only those terms actually required to obtain a result.
- Full evaluation which executes all alternatives.
- Partial evaluation which executes when only a subset of inputs are available.
The result should be the same (modulo choice of error if several could be raised) in all strategies.
The partial evaluation strategy is particularly important. We'd like the behavior to be monotonic: as more inputs become known, the result should be more defined, and once a result value is known, it must not change as more inputs are available. The language must not, for instance, allow a test of whether an input is unknown, as this would allow the result to change value.
CEL follows Protocol Buffers for the numeric types it supports. Since CEL is concerned with the processing of data rather than its storage or transmission, we support only the widest numeric types of a given class of data, i.e. any 32-bit data will be widened to 64-bits. Since
CEL supports both signed and unsigned 64-bit integers. Signed integers use two's-complement semantics, following from the protocol buffers representation.
Range overflow is treated as an error. Exceeding a range is more likely to be the result of a programming mistake than a wise use of the language.
Numeric conversions follow the behavior of ZetaSQL. Perhaps surprisingly, floating point to integer conversions work by the round half away strategy.