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- >boun...@mailinglists.sqlite.org] 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 ><roman.fleys...@einstein.yu.edu> 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 >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 > >_______________________________________________ >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
