On 2017/10/06 6:03 PM, Richard Hipp wrote:
On 10/6/17, R Smith <rsm...@rsweb.co.za> 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 binary
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 "a"
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 the
application with a lot of flexibility with regard to what datatypes
are allowed to be stored in a particular column or participate in an
operation. Other SQL database engines are "rigidly typed". Those
other SQL implementations are much more judgmental about what you can
and cannot do with your data.
(2) Why is rigid typing required in order to implement boolean negation?
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 both
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 there.
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. etc.
It's often used in masking bit flag sequences. a = (a & !0x3) would see
"a" being switched so that it's LSB's 0 and 1 gets switched off while
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), but
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 syntax
like a = (a & (not b))... but that's not how SQLite works, or can work,
unless it becomes strongly typed.
As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
terminology, my point is about the variable sizes not being set in stone.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
