Re: SQL deferred constraints (a bit O/T, I know)

From: David BL <davidbl_at_iinet.net.au>
Date: Mon, 4 Apr 2011 05:50:49 -0700 (PDT)
Message-ID: <8d7e2a4b-88fd-4a51-b311-fa9b260edcb7_at_l2g2000prg.googlegroups.com>


On Apr 4, 8:03 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 4 apr, 04:12, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Apr 2, 11:28 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > TWO : the goal is NOT that "at the end of the session, all constraints
> > > must be _TRUE_", the goal is that at the end of the session, all
> > > constraints must be _SATISFIED_.
>
> > Are you saying that because you don't regard a constraint as a boolean
> > valued expression or function, or because you would never use
> > terminology that ignores the distinction between an expression and
> > what it evaluates to?
>
> The latter. I was complaining about sloppiness in the language.
> Wouldn't you agree that "ignoring the distinction that you mention" is
> indeed sloppy language (or sloppy use thereof) ?

I agree the distinction is important, but I'm not sure about whether we should expect everyone to clarify that distinction in natural language because it's not normally a source of confusion. E.g. it is quite common to make statements like

    "x > 10 is true"

rather than

    "x > 10 evaluates to true".

or

    "the circumference of the circle with radius r is 2*PI*r"

rather than

    "2*PI*r evaluates to the circumference of the circle with radius r" Received on Mon Apr 04 2011 - 14:50:49 CEST

Original text of this message