Which type?
Thank you Dave. So definitely in the Yes camp.
Although, are you sure you are not confusing the obvious point that a string of bits is meaningless without out some knowledge of how to interpret them. I would agree with that.
I'm asking more from a philosophical (i.e. getting a correct model of reality) point of view.
I think that values can (and do) have meaning on their own. I think that values can "standalone" and mean something with recourse to extra information
Take a new(ish) born baby. I'm pretty sure they understand the idea of the value 1 before they know it is of type number. If they see one cat, they know it is one thing, they have some innate (or quickly learnt) concept of oneness, before they begin to conceive of numbers
Or take the value empty , yes I know many would say that is not a value, it has to be empty set , empty string etc... but I don't believe those are values. They are masquerading - they are both the same value, and that value is empty . The set or string parts are really just a constraint on the possible value of a variable. If you have no variables, all you have is the empty value. Indeed it is a logical consequence of my position. If values "have a type", there can't be a (typeless) empty value and visa-versa, if values don't "have a type" there has to be a (typeless) empty and no typed empty values such as he empty list etc
To me, empty is a value and it has no type. Hence why I think the answer to my question is No, scalar values do not carry with them, even "conceptually" their type(s).
If you are in the Yes camp, then you must (logically) also be in the empty is not a thing camp.
Quote from Paul Vernon on November 13, 2021, 8:03 pmThank you Dave. So definitely in the Yes camp.
Although, are you sure you are not confusing the obvious point that a string of bits is meaningless without out some knowledge of how to interpret them. I would agree with that.
I'm asking more from a philosophical (i.e. getting a correct model of reality) point of view.
I think that values can (and do) have meaning on their own. I think that values can "standalone" and mean something with recourse to extra information
Take a new(ish) born baby. I'm pretty sure they understand the idea of the value
1before they know it is of typenumber. If they see one cat, they know it is one thing, they have some innate (or quickly learnt) concept of oneness, before they begin to conceive of numbers
Or take the value
empty, yes I know many would say that is not a value, it has to beempty set,empty stringetc... but I don't believe those are values. They are masquerading - they are both the same value, and that value isempty. Thesetorstringparts are really just a constraint on the possible value of a variable. If you have no variables, all you have is theemptyvalue. Indeed it is a logical consequence of my position. If values "have a type", there can't be a (typeless)emptyvalue and visa-versa, if values don't "have a type" there has to be a (typeless)emptyand no typed empty values such as heempty listetcTo me,
emptyis a value and it has no type. Hence why I think the answer to my question is No, scalar values do not carry with them, even "conceptually" their type(s).If you are in the Yes camp, then you must (logically) also be in the
emptyis not a thing camp.
1 is numeric, whether the concept of "numeric" is appreciated as such or not.
I presume the context here is computation, in which case philosophical interpretations need not apply.
'Empty set' is of type set, 'Empty list' is of type list, 'Empty' on its own is meaningless (particularly, but not exclusively, in computational contexts; i.e., what is it that is empty?) on its own.
Yes, the context is computation, databases specifically as that is my area of interest. I think databases work better when they more accurately model reality. Values are real things. Typing is a way of collecting together two or more values into useful sets. I don't think that in reality, values inherently have some type (or types). Values come first, types are a latter addition.
I don't buy the argument that computation can't model reality (to an unspecified degree of accuracy).
(as I understand, some physicists even think that reality might itself be (or best be understood as) a computation... but that is maybe a bit too philosophical even for me).
Empty is just empty, nought, nothing, no thing. Empty, is (essentially) not a value. It is the absence of a value. (and, looking back now, I should not have said "empty value" in my previous post(s), I should just have said empty and omitted the word value (or replaced it with "thing", but even that is unsatisfactory... often we are very subtly guided/influenced by our language and not always along the right path))
To be clear, I'm happy with the concept of say an empty set variable. I.e. a variable constrained to hold only set values (or to be empty) to be currently empty. I would be happy call that (for the duration that it is empty) an empty set variable. What I would not say is that it holds the empty set value, I would simply say that it is empty - that it currently holds no value at all.
Quote from Paul Vernon on November 13, 2021, 8:52 pmYes, the context is computation, databases specifically as that is my area of interest. I think databases work better when they more accurately model reality. Values are real things. Typing is a way of collecting together two or more values into useful sets. I don't think that in reality, values inherently have some type (or types). Values come first, types are a latter addition.
I don't buy the argument that computation can't model reality (to an unspecified degree of accuracy).
(as I understand, some physicists even think that reality might itself be (or best be understood as) a computation... but that is maybe a bit to philosophical even for me).
Empty is just empty, nought, nothing, no thing. Empty, is (essentially) not a value. It is the absence of a value. (and, looking back now, I should not have said "empty value" in my previous post(s), I should just have said
emptyand omitted the word value (or replaced it with "thing", but even that is unsatisfactory... often we are very subtly guided/influenced by our language and not always along the right path))To be clear, I'm happy with the concept of say an empty set variable. I.e. a variable constrained to hold only set values (or to be empty) to be currently empty. I would be happy call that (for the duration that it is empty) an empty set variable. What I would not say is that it holds the empty set value, I would simply say that it is empty - that is currently hold no value at all.
Values in computing languages invariably have a type1, so that appropriate operators can either be dispatched based on the value type or so that operators can perform operations based on the value type. But, as I mentioned, the type may be opaque in contexts where you're manipulating values as "black box" abstractions -- such as moving them from one system to another, or grouping them in some fashion -- without performing computations on them.
Literals don't have a type (except string) unless interpreted in some context. As such, the keyword empty might not have a type (except string and/or keyword) unless it's in the context of a list and denotes a value, and then it is of type list.
--
1 - Though the type isn't necessarily physically bundled with the value -- at least not at runtime -- but that's more about static vs dynamic typing, etc., and not relevant here. Consider this to be a diversion that might be worth revisiting once you've got a working interpreter and want to make a statically-typed compiler.
Perhaps what you're thinking of, rather than values, are notionally atoms in a language like Prolog (or Datalog). See https://en.wikipedia.org/wiki/Prolog_syntax_and_semantics
I'm not really all that interested in what happens in existing systems (well, obviously I have some interest - and Prolog/Datalog is one system that I suspect I should try to get to know at least a bit.. but I'm not sure that it would be revolutionarily for me ).
What I am interested in is what should happen in some future system. Or in TTM edition 2 words - a Foundation for Future Database Systems.
Quote from Paul Vernon on November 13, 2021, 7:23 pm... Do all scalar values always carry with them, at least conceptually, some identification of the type(s) to which they belong?
No they don't. Consider complex numbers (or any other algebraically closed field). What set does a complex number (which is intuitively a point on a complex plane) belong to? Obviously, to the set of numbers (that is points on the complex plane)!
However, this is not necessarily the only answer. Consider the sets of polynomials of one variable over the complex numbers. Let those sets be closed under addition and multiplication by any complex number. The technical term for such a set is [polynomial] ideal. Now, lets define a binary relation of set membership of a point in an ideal as complex point being the root of all the polynomials from the ideal. To satisfy the axiom of extensionality we need to focus on the radical ideals, but there is nothing in the set theory which prevents us from viewing radical ideals as sets of points, while they are "obviously" sets of polynomials!
Please note the analogy with the database field. What is the database relation made of? Is it a set of tuples, or a set of columns? OK, you might probably raise an objection that you have demanded the values to be "scalar", which, at first, seems to exclude database relations. I don't agree: the definition of something being "scalar" is quite fuzzy, and the relational algebra certainly makes the database relations to look like scalar entities.
Quote from Paul Vernon on November 13, 2021, 9:29 pmI'm not really all that interested in what happens in existing systems (well, obviously I have some interest - and Prolog/Datalog is one system that I suspect I should try to get to know at least a bit.. but I'm not sure that it would be revolutionarily for me ).
What I am interested in is what should happen in some future system. Or in TTM edition 2 words - a Foundation for Future Database Systems.
What should happen in any computational system is that values should be identifiable as to their type, so that you can appropriately dispatch type-specific operators to operate on them.
Otherwise, your values must be opaque and therefore can support no operators. They can't even be compared for equality, which is fundamental to any implementation of the relational model.
But you could treat all values as a single type "bit string" -- binary objects -- and only support equality. Some NoSQL systems do that.
Or, you could treat all values as a single type "bit string" and let the user choose operators -- which assume the type of their bit string operands -- based on his or her knowledge of what type(s) a given bit string must be at the point of every operator invocation in a program. FORTH and most assembly languages do that.
Or, all values could be type "character string" -- text objects -- and support the usual numeric, string, boolean, and other operators. Some SQL and NoSQL systems do that. Such systems are notionally simple, but inevitably raise considerations that are fundamentally about type systems. E.g., should the result of adding "2" and 2 be "22", 4, or a (runtime?) error?
Or, values could have specific types and support the usual numeric, string, boolean, and other operators.
Etc.
Quote from Paul Vernon on November 13, 2021, 7:23 pmI think I'm still curious as to what the contributors to this thread (and any lurkers) actually think the answer is to my original question.
So for some undefined meaning of the word do; Do all scalar values always carry with them, at least conceptually, some identification of the type(s) to which they belong?
Valid answers are: Yes, No, Don't know, Don't care, It depends, If you want them to, It does not matter, Yes and No, Impossible to say, If you declare it so, ... or any other answer as long as it is of no more than say 5(ish) words.
Personally I think: No.
or at least, I don't think it is useful or needed to conceive that they do (OK, so that is more than 5(ish) words :-( )
Then you are mistaken. In any given programming language every value has an associated type (or perhaps more than one). There are no typeless values in programming languages.
Elsewhere value has a variety of different meanings, so the answer is: it all depends on the context.
No as a blanket position is not the right answer.
Rather than (probably pointlessly) debate individual points, I'll point out that I am at least somewhat sympathetic to your approach. Though I would expect which types are available by default to be a product implementation concern only, as there isn't any theoretical basis for it. As a theoretical framework for applied implementations, TTM takes exactly the right approach in not prescribing specific types -- beyond the unavoidable boolean -- but it does appropriately prescribe how (Date & Darwen believe) types should be built.
I would expect that (or similar) ability to define any and all types in any post-SQL DBMS, completely independent of whatever types a given product implementation may or may not provide on boot-up.
In short: Provide whatever built-in types you feel are appropriate in your implementation, but they don't belong in a conceptual framework like TTM, and a reasonable product should neither compel their use or limit the user to only that set as primitives or baseline types.
Just humour me for a moment: forget about programming languages, forget about application building, forget about the motivation of TTM and whether it is still relevant. Just think about the data.
Assume you wanted to foster a large community of data producers and consumers, all using different toolsets, and you were trying to devise a type system to facilitate data publication, interchange and reuse. It has to be easy to work with in any language, and it has to have really wide coverage, to reduce the temptation to add private types.
The lingua franca at present seems to be a choice between CSV files, Excel spreadsheets and JSON.
- CSV is horrible and supports text string only; data snooping can give you boolean, text, integer, decimal, real, date/time, enum. Mistakes are really common.
- Excel supports text string, real; via formats it supports integer, decimal and date/time; data snooping can give you boolean, enum.
- JSON supports boolean, text string, real, and struct; data snooping can give you integer, decimal, datetime, enum.
Why would you not prefer a standard for data models and interchange based on my nine types? Currently there is no standard way to model or exchange binary strings, and many of the commonly used methods depend on data snooping.