Skip to content
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

Internal DSL for Predicates? #19

Open
epage opened this issue Apr 1, 2018 · 6 comments
Open

Internal DSL for Predicates? #19

epage opened this issue Apr 1, 2018 · 6 comments
Labels
question Uncertainty is involved

Comments

@epage
Copy link
Contributor

epage commented Apr 1, 2018

iirc Rust's logical operators force a return type, preventing using them in a DSL (pred && pred).

What about the bitwise operators (pred & pred)? Should this be done to make the API "more ergonomic"?

What about not-ing? And if our choice in operator for not-ing is at a weird precedence level compare to the others, which should we prefer?

@epage epage added the question Uncertainty is involved label Apr 1, 2018
@nastevens
Copy link
Collaborator

Yeah unfortunately pred && pred isn't possible because it requires a bool be returned immediately. Currently && doesn't appear to be overloadable. I came from C++ where operator overloading got grossly misused, so I don't really like the idea of "close enough" operators. & is not the same as && in my mind, so I would be opposed to using it to desugar to and().

not()/! on the other hand could be really useful because the ordering is currently weird. Whereas pred1.and(pred2) and pred1 && pred2 read in the same order, pred1.and(pred2.not()) introduces the weird trailing not(). The sugared version pred1.and(!pred2) reads so much nicer and just feels natural.

@epage
Copy link
Contributor Author

epage commented Apr 3, 2018

Not seeing a good way to provide a single implementation of Not. Instead we need to provide an implementation per predicate. Probably best to wait for #18 to get in.

I assume a not function should still exist in some form. We could keep the existing one but I worry about weird corner cases of the Not trait being in scope causing compiler errors for our users. That leaves just moving not to be predicate::not or finding an alternative name.

@luser
Copy link
Contributor

luser commented Jul 26, 2018

I was going to open an issue about not, but sounds like you've already got ideas there. Having it as a method on a predicate makes them very awkward to read. It'd be way nicer to be able to say predicate::not(...).

@asomers
Copy link
Contributor

asomers commented Jan 23, 2019

It would be easy to do this with a proc macro. You could write something like this:

pred!{predicate::gt(5) && predicate::lt(10)}

However, it would require the proc_macro_hygiene feature, which is not yet stable.

@matthiasbeyer
Copy link

When I clicked on this issue I thought this was about having a parser for a DSL that can be parsed into a Predicate. So that a user can specify some predicate "less_than(5).and(greater_than(0))" in, for example, a configuration file, and the software can then parse this into a BoxPredicate (for example) and apply it to some stream of data. Just as an example.

Or does such a thing already exist somewhere and I just missed it?

@epage epage changed the title Predicate DSL? Internal DSL for Predicates? Apr 8, 2022
@epage
Copy link
Contributor Author

epage commented Apr 8, 2022

I've clarified the title to be about an internal dsl. I am not aware of an external dsl.

epage added a commit to epage/predicates-rs that referenced this issue Apr 26, 2024
chore(ci): Ensure CI job always runs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Uncertainty is involved
Projects
None yet
Development

No branches or pull requests

5 participants