Should we rename whereExists and whereNotExists to present and absent?

[ocharles]

@shane-circuithub proposes that we rename whereExists to present, and whereExists to whereNotExists (#57). This will ultimately be a breaking change (though we would likely deprecate the existing functions and gradually remove), but we're not able to reach an agreement as to whether or not we should do this. We'd love to hear feedback to help us make a decision!

Proposal: Rename whereExists to present and whereNotExists to absent.

Argument for: I think the names whereExists and particularly whereNotExists are fairly unwieldy for something that corresponds to such a nice algebraic operation in the underlying relational algebra, i.e., semijoins and antijoins respectively. If they weren't just literal translations of the SQL they generate, I don't think we would have ever chosen those names for a Haskell combinator. I think it's important to have short, concise names for foundational algebraic combinators, because it leaves room for other people to come along and define variations of them with prefixes and suffixes. This is the pattern throughout most of Rel8, with optional, many, and our heavy reliance on monadic composition of queries. I don't think the names whereExists and whereNotExists do their combinators justice. Even if users may not be familiar with present and absent at first glance, the names do capture both what they do and their relation to each other, and I think this precision and their conciseness will allow them to be quickly internalised by users.

Argument against: I think whereExists and whereNotExists appeal to intuition, assuming the user is familiar with SQL. If I'm reading Rel8 code, I can have an idea what whereExists will do, while present is unfamiliar, both in SQL and Haskell (as far as I'm aware). present is ambiguous in isolation (though unambiguous when paired with absent), and I worry people may interpret present as "presenting" a Query, rather than checking for the presence of rows.

Alternatives:

• Add present and absent, leaving whereExists and whereNotExists unchanged (and not deprecated).
• Use a different renaming?

[JulianBirch]

I far prefer present but I also like to see booleans with verbs e.g. isPresent. Adding the verb solves the ambiguity as well.

[typedfern]

Also in favor of present and absent (or, alternatively, has or having - also like @JulianBirch's isPresent - clauses should sound like yes/no questions)

[shane-circuithub]

I wonder if there's some confusion based on the comments. Just to clarify, we're talking about these operators here:

whereExists :: Query a -> Query ()
whereNotExists :: Query a -> Query ()

Not this operator here:

exists :: Query a -> Query (Expr Bool)

whereExists and whereNotExists, though they can be implemented in terms of exists, they don't by themselves really have anything to do with the boolean value returned by exists. They correspond to the semijoin and antijoin operations from relational algebra, like so:

semijoin :: Query a -> Query b -> Query a
semijoin a b = a *> present b

antijoin :: Query a -> Query b -> Query a
antijoin a b = a *> absent b

[typedfern]

Yes, there was confusion on my part; thanks for clarifying!

Still in favor of present and absent - I withdraw the suggestions about yes/no questions, but having and notHaving still could be a possibility - specially if we use it as an infix connective:

employees `having` dept

[shane-circuithub]

absent and present are unary operators, so you wouldn't be able to write them infix, but you can use *> to achieve a similar effect, i.e., employees *> having dept.

[ocharles]

Note also the "infix" solution already kind of exists with with:

employees >>= with dept