-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow modifying the AST in Parse time #366
Labels
enhancement
New feature or request
Comments
As a first step, the plan is to introduce validators (#762) to allow for custom AST validations to be run after type-check. Once the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature request checklist
I think it's preferable to open an issue instead of a PR because:
Change
@lopezator asked in #359 if not checking the sanity of values inside known function overloads in
Compile
time was an expected behaviour. And it was, there is no constant value checking meaning thatCompile
(Parse
+Check
) won't complain about these kind of expressions:birth_date >= timestamp("invalid-date!")
.Although @TristonianJones said that there would be a possibility in the future to include linting rules to
Compile
that doesn't fully solve our problem. We're using CEL to parse (& check!) the filter (https://google.aip.dev/160) attribute in our List API calls (https://google.aip.dev/132). Then with the resulting AST we convert it into our WHERE clause in the SQL SELECT statement.The point is that if the AST is left unmodified the AST->SQL WHERE (or whatever filtering language) converting layers gets more complicated than they should because they need to take care about those intermediate functions by themselves.
Ideally for us,
Compile
would have an option to contract those constants and optimize the AST. But it could also be possible to achieve exactly the same optimized AST with the decorators thing @TristonianJones proposed here and lettingcel-go
users by writing that logic outside of the library.Alternatives considered
Using
cel.Program
withEval
in combination ofOptOptimize
but it would only check if the expression is valid, the original AST unmodified.The text was updated successfully, but these errors were encountered: