cel-spec

CEL looks interesting and useful, though it isn't common nor familiar imo (not for me at least). Quoting from https://github.com/google/cel-spec # Common Expression Language The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate. ## Key Applications - Security policy: organizations have complex infrastructure and need common tooling to reason about the system as a whole - Protocols: expressions are a useful data type and require interoperability across programming languages and platforms.

Yes but when you combine it with the other guarantees on performance. https://github.com/google/cel-spec/blob/master/doc/langdef.m... And your service puts an upper bound on input size and cel expression size. (True for all practical applications.) You can actually get a guarantee tha t you can't construct a billion year expression. And even guarantee that all expressions will evaluate in let's say 60 secs. Turing completeness by itself does not guarantee this but it is a necessary prerequisite for these guarantees.

CEL seems to be for proto-buffers[1], not text? [1] https://github.com/google/cel-spec/blob/master/doc/intro.md CEL-go: https://github.com/google/cel-go

CEL is becoming a "standard" implementation found in a lot of places. I generally like it, but loathe how much it's been growing the Yaml Engineering (devops) space. We need better options like CUE and Starlark that can scale and CEL feels more like duct tape in a lot of places. You kind of need CEL-in-config when the values are dynamic and processed within another system. In time, I expect that if something like GitHub Actions supported CUE natively, we could remove the `when: "CEL expression"` even with the dynamic values from previous steps. Eventually CUE's evaluator will be smart enough to know when / how to order sub-values. - https://cel.dev - https://github.com/google/cel-spec

My employer uses a combination of Protocol Buffers (for the config schema definition) and Bazel/Starlark (for concrete instantiations). Configs are validated at build time and runtime using CEL (https://github.com/google/cel-spec).

Google's proposal for filtering: https://google.aip.dev/160 Specifically, https://google.aip.dev/assets/misc/ebnf-filtering.txt which is a modification of their common expression language https://github.com/google/cel-spec

XML is overwrought, YAML is a foot-bazooka, JSON lacks comments, TOML gets unwieldy with more than a few levels of nesting, EDN is neat but kind of obscure... Maybe we need a new configuration format... ducks Actually I think something in the space of JSON5, Jsonnet, GCL, HCL, CUE, etc, will be the one to win out in the long run. JSON-but-fix-most-of-the-warts. Then there's things which almost sit between fully declarative and turing-complete. Maybe Dhall, if it picks up a few more language implementations. Or CEL. https://github.com/google/cel-spec

Google has a CEL (common expression language) that seems easier to understand and extend: https://github.com/google/cel-spec Using CEL for writing IAM policy: https://cloud.google.com/iam/docs/conditions-overview

Btw google have something almost exactly like this: https://github.com/google/cel-spec

This project reminds me quite a bit of [0] which I'm currently using to write rules to parse tags from Openstreetmap. Having a standard way to share expressions does seem quite useful, especially when it's multilingual. [0]: https://github.com/google/cel-spec

Hi, I'm Tristan (@TristonianJones), the lead of the CEL project here at Google which has a few core maintainers as well as a number of regular contributors: https://github.com/google/cel-spec/blob/master/MAINTAINERS.m... Macros are considered an optional feature of the language because they can: a) easily be disabled, b) have no dedicated syntax beyond that defined for core CEL. CEL supports subsetting and extension which means you can actually turn off built-in features in order to guarantee a sort of maximal compute / memory impact that an expression might have while still augmenting the core feature set in order to tailor it to your use case. Bounded iteration is possible via macros, and such iterations can be nested; thus, you can have high polynomial time expressions, but only if you choose to permit them and many use cases (like I

Genuine trinary logic so exceptions are mapped to unknown but can still short circuit the overall expression. https://github.com/google/cel-spec/blob/master/doc/langdef.m...