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
