Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Expression Language

github.com

Post reply on HN
Print view View original

51–60 of 111 posts

Re: Common Expression Language

#51

Post by codebje »

progval wrote: post #27
contravariant wrote: post #15

I'd be a bit suspicious about the claim that it is not Turing complete. To be fair I can't yet find a way to allow arbitrary computation (though it seems easy to add one with fairly innocuous features). Although you can get it to solve 3-SAT, though only for some predefined number of variables (which it assures can be at least 32). Combinatorics stuff like printing all possible sudokus also seems like it should be fe…

> Although you can get it to solve 3-SAT, though only for some predefined number of variables (which it assures can be at least 32). Combinatorics stuff like printing all possible sudokus also seems like it should be feasible. How is this compatible with their claim that "CEL evaluates in linear time"?

The only place I can find that makes the 3-SAT claim is this comment thread.

Nevertheless, there's two answers I can think of here. The first is simple (but IMO probably not right): 3-SAT is (probably) exponential, but the language definition document qualifies the linear claim by saying that macro expansion can also be exponential.

The second is probably more accurate, though. General 3-SAT is (probably) exponential, but we're dealing with 3-SAT for a constant number of variables. You can solve 3-SAT by producing all combinations of values for the variables and testing the expression for each one, but while testing an expression should be linear there's an exponential number of combinations. If your combination count is constant, though, the whole complexity becomes linear ... with a shockingly bad constant factor.

Re: Common Expression Language

#52

Post by jhhh »

derefr wrote: post #42
throwaway894345 wrote: post #8

Earlier quoted context omitted.

I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…

What about the option of just writing a regular, one-off program in a regular programming language , the output of which is your baked YAML config; and then having a pipeline that involves running that config-generator program, piping its output to your orchestrator of choice? Nearly every programming language has a YAML serialization library†. And before that serialization happens, your config can be expressed using…

After trying to write complex loop statements and conditionals in yaml for ansible I had this thought as well. It's nice when declarative configurations work, but once they don't and you have to try to write a real program in yaml you'll want to pull your hair out.

Re: Common Expression Language

#53

Post by iampims »

throwaway894345 wrote: post #11
didip wrote: post #10

Earlier quoted context omitted.

I am with you, I wish the world would just adopt Lua as their config files.

I haven't used Lua, but I've used Starlark extensively and I will say that static typing is a boon, especially in the infra-as-code space where the feedback loop can be very long.

Good news. Starlark-go finally supports protocol buffers, so at least the output of your script gets some type checking.

Re: Common Expression Language

#55

Post by Tabzz98 »

throwaway894345 wrote: post #8
frou_dh wrote: post #5

I remember seeing this used inside config files for the Caddy webserver. Google seem to like these executable config languages because they've got another open source one ("Starlark") a few notches up in expressivity.

I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…

I would love to know your thoughts about https://github.com/pragmalang/pragma

Re: Common Expression Language

#56

Post by lmm »

derefr wrote: post #42
throwaway894345 wrote: post #8

Earlier quoted context omitted.

I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…

What about the option of just writing a regular, one-off program in a regular programming language , the output of which is your baked YAML config; and then having a pipeline that involves running that config-generator program, piping its output to your orchestrator of choice? Nearly every programming language has a YAML serialization library†. And before that serialization happens, your config can be expressed using…

At that point why use YAML at all? If it's generated by a program and fed to a program, you're better off using protobuf or something like that. In fact, since you're probably using the same language on both ends, why not just write a regular value in your language?

This probably sounds like a strawman, but it's not. It's how a lot of e.g. Python projects are configured - the "config" file is just a normal bit of code that gets run to produce a value. Unless you're using a programming language that absolutely sucks at expressing plain values (e.g. C or Java), it's much better than separate config files, IMO.

Re: Common Expression Language

#58

Post by partialstate »

codebje wrote: post #51
progval wrote: post #27

Earlier quoted context omitted.

> Although you can get it to solve 3-SAT, though only for some predefined number of variables (which it assures can be at least 32). Combinatorics stuff like printing all possible sudokus also seems like it should be feasible. How is this compatible with their claim that "CEL evaluates in linear time"?

The only place I can find that makes the 3-SAT claim is this comment thread. Nevertheless, there's two answers I can think of here. The first is simple (but IMO probably not right): 3-SAT is (probably) exponential, but the language definition document qualifies the linear claim by saying that macro expansion can also be exponential. The second is probably more accurate, though. General 3-SAT is (probably) exponential…

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 IAM Conditions) don't. This is different from OPA Rego or HashiCorp Sentinel in that these features are baked into the syntax and impossible to turn off with 100% certainty.

Since you can't declare functions or variables within CEL, the environment of an expression (the variables and functions it can use) is completely controlled by the host process. The environment acts like a sandbox of sorts, but one specifically chosen by the application and not a general purpose mechanism like a hypervisor or sandbox like WebAssembly.

Re: Common Expression Language

#59

Post by partialstate »

asciimike wrote: post #14
hardwaresofton wrote: post #9

This looks really similar to Open Policy Agent[0], wonder how they compare. [0]: https://www.openpolicyagent.org/

I'll let Tristan or Torin comment more authoritatively, but back in 2017/8 CEL partnered with OPA and I believe CEL was used as the basis for expressions in their new version of Rego. I left the team about that time, so I don't know what exactly happened after that, but I wouldn't be surprised if the two are fairly close. My assumption is that's why CEL is polished up and OSS (I think we first published it a few year…

OPA Rego and CEL are distinct, but you can see similar thinking in OPA Gatekeeper and CEL Policy Templates (https://github.com/google/cel-policy-templates-go) which are aimed at separating config from policy in order to create a better user experience. Note, the CEL Policy Templates are early in development, but build upon the abstractions provided by CEL.

Re: Common Expression Language

#60

Post by partialstate »

hadrien01 wrote: post #2

At the end of the README: Disclaimer: This is not an official Google product.

Unless the open source is part of a paid offering (like Firebase CLI), it's required to be listed as not being an Official Google Product. That said, CEL is used in a number of publicly supported Google Cloud services which means that it's well supported with dedicated maintenance. Case in point, I'm the CEL lead at Google.
Post reply on HN