I'm honestly not really sure these names add much beyond what we already have. They don't match anything I'm already familiar with as a Haskeller, and it breaks the slight symmetry we have with where_.

whereExists and whereNotExists to me feel like ugly SQLisms, it's just translating the SQL literally into Haskell. I don't mind the names semijoin and antijoin, but those names sound like they should be for binary operators, whereas these are unary (but are equivalent when used applicatively/monadically). I feel like we've always lacked a nice concise name for the "unary" versions. And just because Haskell doesn't have any well known idioms for semijoins doesn't mean we can't be the ones to change that! 🙂

But yeah, whereNotExists in particular is already too unwieldy for my liking, but now that I've figured out how to make Tabulation versions of these, I'm definitely not going to want to be typing whereNotExistsTabulation. But absentTabulation is fine. I guess that's one of the reasons I strongly prefer shorter names for concepts like this: they're more morphologically productive. Whereas long names are already morphologically saturated and so can't really be built upon. But semijoins and antijoins are such natural concept in relational algebra that it definitely makes sense to leave morphological "room" for people to build upon them.

Does that make sense?

I understand a bit of your comment, though you have lost me at morphological. I'm afraid I'm still struggling to see a benefit in present and absent, so not really sure what to do. I would say that tabulation is already such a unique concept, I am OK with presentTabulation and stuff. In fact, if we don't use the names present and absent, you could even just use those.

Discussion is being continued at #65