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