I'm also really starting to wonder whether we should consolidate the two crates into a single one, wdyt@clarkmcc ? I just find it harder to see how to lay the code into files... and mostly it feels like so much going into the parser. All that making it into the public API (pulling e.g.usescel-parser::Value to then work with thecel-interpreter::Context for instance)

@alexsnaps the only reason to keep them separate arethese use-cases. If it's going to create a maintenance burden or technical debt in order to specifically support the parser being used in non-CEL contexts, then I am comfortable consolidating to a single crate. While it's nice to accommodate other non-CEL use-cases, those use-cases can still use the parser as part of the single interpreter crate.

@alexsnaps the only reason to keep them separate arethese use-cases. If it's going to create a maintenance burden or technical debt in order to specifically support the parser being used in non-CEL contexts, then I am comfortable consolidating to a single crate. While it's nice to accommodate other non-CEL use-cases, those use-cases can still use the parser as part of the single interpreter crate.

I sorta get the rational, tho... possibly not. As far as I can tell, supporting these use-cases "only" requires the crate to expose whatever is needed to create an AST to be accessible to the end user. Now that remains the case either way as that's howCEL phases are defined.

If we're talking requiring users of the parser to pull "too much" within the compile unit, then... possibly. Tho all they don't use would be DCE'ed anyways, but arguably that's not a free thing and will make their compilation, if only initially, slower. But that's where I fear things are going to get more obvious as I progress with this: there will be a whole lot more than "just the parser" in thecel-parser crate, as the whole type system is being pulled in. Also note, that the release and API burden does "somewhat" existtoday, as there is a hard dependency between parser & interpreter version.

Now I will try to keep the parser "as lightweight as possible" for now and see how far I can get, we can always re-evaluate later. So I'll keep all traits in the parser, along side with the literal types. Ithink I can possibly split some types out of the parser into the interpreter (thinking of container types here, but I could be wrong). I still think this is somewhat fighting the design of the other reference implementation, where these shared things are in a "common" package/module/subproject, but I would really hate to add a 3rd crate. Until I'm further along, these things will then go intocel-parser::common, is that fine with you?

@alexsnaps I mean I think you make a compelling case for unification. I'm comfortable with that.

@alexsnaps I mean I think you make a compelling case for unification. I'm comfortable with that.

It's mostly the design that we're porting that from that makes that case. Tho, I'm also trying to avoid too many or certainly unnecessarydynamic dispatches... Which could become the case if I "hide" certain things behind atrait "just" for the sake of the dependency. I'll keep on iterating for a few days, and then we can hopefully make a call informed by actual code.