Practical language-agnostic example: a database for a business where some VARCHAR(34) columns are IBAN codes and others are messages to be displayed on a 2 by 17 characters LCD screen.
They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model.
For instance, it should be possible to turn an IBAN into a device screen message but not the opposite, but you can't do it if they are all "strings"; and the two types have different value constraints while a generic VARCHAR has none.
> They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model.
About bools: that's my problem with this. If-statements now operate on anything, instead of just bools. And I don't think that makes sense, unless cheese.
About strings: It's great you can statically differentiate between their types. But if strings don't exist, it makes it a little hard to write WHERE clauses.
They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model.
For instance, it should be possible to turn an IBAN into a device screen message but not the opposite, but you can't do it if they are all "strings"; and the two types have different value constraints while a generic VARCHAR has none.