feat: new expression builders

[a10y]

For binary expressions, we now have eq, not_eq, lt, lt_eq, gt, gt_eq, and, or (see vortex-expr/src/binary.rs). Add example usage doctests for all

For literals we have lit

For Identity we have ident

[a10y]

One thing I noticed while writing these doctests is that we don't have a nicer generic way of building a BooleanBuffer. You need to build a full BoolArray and then access its arrow booleanbuffer.

I added a macro so you could do something like bools![true, false, true] but that still forces you to bring in an arrow_buffer dep. We should probably use and return our own booleanbuffer type to make this more ergonomic

[lwwmanning]

Yeah, we need to make our own BooleanBuffer type... relatedly, #1774

[robert3005]

You can construct BooleanBuffer directly from Iter<bool>

[a10y]

Yea but then you need to add a dep on arrow_buffer where there wasn't previously, and sadly rust doesn't let you enable a dep only for doctests

[a10y]

oh actually I'm wrong, apparently doc tests use dev-dependencies

[a10y]

An alternative that is a bit closer to what Arrow does is to implement the binary operators as method chains.

[robert3005]

I think we should do this instead of chaining. Chaining is nice but not sure correct if our expressions are not an enum

[gatesn]

I don't know what you mean @robert3005 ? Can we do chaining too? It's better for discoverability.

[robert3005]

We can do chaining but it's unclear how chaining works in general for arbitrarily extensible traits. Datafusion does chaining for Expressions not PhysicalExpression

[gatesn]

Can add(lhs: ExprRef, rhs: ExprRef) be:

pub trait ExprExt: Expr {
   add(self: Arc<Self>, rhs: ExprRef) -> ExprRef {
     ..
   }
}

impl<E: Expr> ExprExt for E {}

[robert3005]

Yes, you can do this. You still need to have many traits like that since not all expression will be defined in one place.