On Tue, Sep 29, 2026 at 8:20 AM Vik Fearing <vik@postgresfriends.org> wrote:
> On 24/09/2026 16:33, Nathan Bossart wrote:
> > 2) I cannot come up with any natural examples to illustrate the desired
> > behavior. Take the following example:
> >
> > shipped IMPLIES zip code set IMPLIES ship date in the past
> >
> > Under right associativity, this would translate to
> >
> > NOT shipped OR NOT zip code set OR ship date in the past
> >
> > The former reads as "if shipped, then the zip code is set and the ship date
> > is in the past", but the latter is pretty obviously not that.
For the very little it's worth, I agree with Nathan. I tend to intuit
A => B => C
as meaning
(A => B) and (B => C),
probably because that's kind of how you would write it in an informal
proof? Forcing parentheses would make you write what is meant, which
is a property I enjoy when I'm trying to understand SQL queries
written by someone who is not a logician or a Haskell programmer. :D
> I will make sure this is settled with the committee long before v20 hits
> feature freeze. I don't expect them to contradict me on this because
> all languages that have this operator (e.g. Haskell, Rocq, Agda, TLA+,
> SMT-LIB, Alloy, Isabelle, etc) all use right associativity.
>
> The precedent for right associativity is enormous.
(Well, but that's presumably because those languages are tightly tied
to function currying, proofs, and related mathematics, right? Doesn't
feel like that applies to your typical CHECK constraint.)
Either way, you don't really need to convince me; I just wanted to +1
Nathan's "no associativity" idea and run away. And associative or not,
IMPLIES is a lot nicer than the NOT-OR construction.
Thanks!
--Jacob
