On 2017/10/08 3:56 PM, 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 redundant.

The first paragraph is just not true.

The second one alludes to why the misunderstanding exists. Perhaps a quick browse through the meanings of "weak" and "strong" typing would clear that up. My quick google attempts yield:
http://wiki.c2.com/?WeakAndStrongTyping
https://en.wikipedia.org/wiki/Strong_and_weak_typing
http://www.i-programmer.info/programming/theory/1469-type-systems-demystified-part2-weak-vs-strong.html
https://en.wikipedia.org/wiki/Duck_typing

To be clear, I wasn't disagreeing with Richard on his point of naming it "Flexibly strong typed", and my notion of "strongly typed language" perhaps gave the impression that I thought the opposite of SQLite (i.e. that is "weakly" typed), which isn't the case - I think it's closer to Duck Typing (see the last link above). Most scripting languages prefer the weakly typed model (maybe I should be careful and say "lean towards the weakly typed model" rather), and most compiler languages lean towards strongly typed. That isn't to say there's no confluence or bridge-crossing, there is in fact a lot.

SQLite's typing system is great, but you can't tell me for certain the predicted size of a column of integers. Some will take less bits than others, based on the value of the actual Integer. Inside functions SQlite will try interpret strings as numbers if the function expects a number and vice versa - very useful, but the very definition of weakly (read: Dynamically) typed languages. In other instances, SQLite behaves much more like strongly/statically typed language needing a CAST() to correctly handle values and the like.

Either way, a unary value-based NOT operator is not feasible because the bit-size of an Integer value is not predetermined or specified. Unless maybe it always returns a 64-bit value.


_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to