And the underlying processor has no such thing as a "type" -- it is simply a 
high level abstraction designed to keep the ill equipped from cutting their 
hands off by grabbing the wrong end of the knife...

The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>] On Behalf Of Peter Da Silva
>Sent: Sunday, 8 October, 2017 08:40
>To: SQLite mailing list
>Subject: Re: [sqlite] XOR operator
>Generally, when you talk about whether a language is strongly or
>weakly typed, you're talking about the storage, not the content.
>Pretty much every "weakly typed" language out there (there are a few
>exceptions, like Tcl) does have fully typed values. In many cases you
>can even interrogate the value with a "type of" operator. They just
>have storage locations (variables, array elements, hash targets) that
>can hold any type.
>SQLite is, in common terminology, weakly typed.
>> On 2017-10-08, at 08:56, Roman Fleysher
><> wrote:
>> The point is that terminology is chosen for a reason and can not be
>dismissed. "Flexibly typed" means it is typed. It means SQLite knows
>how many bytes: without knowing it would not be able to establish
>equality "IS".  Flexibly means columns can contain values of mixed
>types,  but each value still has a type. And this is a very very big
>advantage of SQLite.
>> Perhaps longer term is "flexibly strongly typed". Perhaps because
>"typed" implies "strongly" (what is a weak type?), strongly is
>> Roman
>> -------- Original message --------
>> From: R Smith <>
>> Date: 10/8/17 9:38 AM (GMT-05:00)
>> To:
>> Subject: Re: [sqlite] XOR operator
>> On 2017/10/06 6:03 PM, Richard Hipp wrote:
>>> On 10/6/17, R Smith <> wrote:
>>>> I'd also like to see a Unary NOT operator, such that you can say:
>a = !b
>>> In SQL and SQLite that would be:  a = NOT b
>> Apologies, I thought it obvious from the context that I meant a
>> operation, not a Boolean operation NOT.
>> i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so
>if a
>> = 0xA then !a = 0x5, but that only works IF we are restricted to
>> being 1 byte in size, which brings us to the following point:
>>>> But, I guess that's only feasible in a strongly typed language.
>>> (1) I object to the characterization of SQLite not being "strongly
>>> typed".  SQLite is "flexibly typed" in the sense that it provides
>>> application with a lot of flexibility with regard to what
>>> are allowed to be stored in a particular column or participate in
>>> operation.  Other SQL database engines are "rigidly typed".  Those
>>> other SQL implementations are much more judgmental about what you
>>> and cannot do with your data.
>>> (2) Why is rigid typing required in order to implement boolean
>> Answering (2): A strongly typed language that defines
>> INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
>> signed/unsigned representation, or "Byte" as a 8-bit unsigned
>> representation will be sensible to say a = not b; where a and b are
>> typed as BYTE values. but if you don't know how many bits are
>"meant" to
>> be in "a", how to determine how many bits must be negated /
>"notted" /
>> changed to produce the result of "NOT b" in the way described up
>> If for example a = 0xA then !a might be 0x5 for a nibble, but it
>will be
>> 0xF5 for a byte, 0xFFF5 for a WORD, 0xFFFFFF5 for a 32bit INT, etc.
>> It's often used in masking bit flag sequences. a = (a & !0x3) would
>> "a" being switched so that it's LSB's 0 and 1 gets switched off
>> leaving the others in tact. Yes, I could have just said a = (a &
>(0xFF -
>> 0x03)) or even work out what that result is and go a = (a & 0xFC),
>> if the bits that get switched off lives in a variable (b), then a =
>(a &
>> !b) is just so much more sensible / elegant. I'm even ok with
>> like a = (a & (not b))... but that's not how SQLite works, or can
>> unless it becomes strongly typed.
>> As to (1)... Cool, call it flexibly typed then, I'm ambivalent to
>> terminology, my point is about the variable sizes not being set in
>> _______________________________________________
>> sqlite-users mailing list
>> _______________________________________________
>> sqlite-users mailing list
>sqlite-users mailing list

sqlite-users mailing list

Reply via email to