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 redundant. Roman -------- Original message -------- From: R Smith <rsm...@rsweb.co.za> Date: 10/8/17 9:38 AM (GMT-05:00) To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] XOR operator 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 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
