Template talk:Data types

Template rationale

This bottom-style navbox template is intended to organize the articles about computer science data types.

Data types are a programming language concept, and should not be confused with the mathematical concepts that they (try to) emulate, nor the internal representation (encodings and data strcutures) that are used to implement them. Thus, for example, tuple is a mathematical concept; record (computer science) is both a data type in many languages and a data strcuture. Linked list and Tree (computer science) are data structures, while list (computing) is an abstract data type or abstract data structure that may be a data type in some languages. Also twos complement is one possible representation of the data type integer (computer science) which is an emulation of a mathematical integer. Admittedly, the dividing line between data types and data strcutures is often blurred, but there is a Template:Data structures for data strcutures.

I propose that this template only lists only the most common data types and "top-level" articles, leaving the specialized versions to be accessed through them. So, for example, unsigned integer should not be listed directly; readers can get to it either through the integer (computer science), or through the "Data types" category. Trying to list all data types that have ever been used in any programming language would make the list too big and turn it into a duplicte of the category page, frustrating the very purpose of the navbox (provide a structured access to the subject). It would also make this navbox hard to maintain. On the other hand, given its low profile, this navbox can probably be included in almost every article in the "Data types" category.

All the best, --Jorge Stolfi (talk) 15:44, 9 May 2009 (UTC)

Correctness of including Stream and Exception

I find the classification of Stream and Exception as datatypes questionable. --Cybercobra (talk) 03:52, 10 May 2009 (UTC)

I am not convinced either that they deserve to be mentioned in the template. However, Exception was a built-in data type in Modula-3, and Ada, and perhaps Common lisp. I recall at least one language where streams (there called "channels" were built-in types; owe you a reference to that. All the best, --Jorge Stolfi (talk) 17:13, 10 May 2009 (UTC)

Cons cell is not a fundamental data type

"Cons cell" is not a data type. It is a special case of record (like complex, interval, rational, and infinitly many more), or like the nodes of a linked list. Jus as "node of lined list" does not deserve an article, a "cons cell" does not either. Besides the cons article is more about the cons function than the data type. The main built-in LISP data type is S-expression, not cons cell, and should be listed as such. All the best, --Jorge Stolfi (talk) 17:30, 10 May 2009 (UTC)

Ok, then I would likewise hold that sexprs are just a particular language-specific physical representation of record and thus don't deserve to be in the list. They're a serialization representation, not a unique data type. --Cybercobra (talk) 23:30, 10 May 2009 (UTC)

I would say that the cons cell is a particularly notable special-case of a record. Lisp and some other languages lack a pointer datatype, but make up for this by having cons cells and create all composite datatypes out of just the humble cons cell, which is fundamental/primitive and cannot be created in the language itself (the cute toy implementation using lambdas notwithstanding). And you're being a bit inconsistent. Complex, interval, and rational are in the template, yet as you yourself say, they too are special cases of record; so your reasoning for not including cons cell doesn't quite make sense to me. Not that I think complex and friends should be removed from the template. --Cybercobra (talk) 23:39, 10 May 2009 (UTC)

I am striving to find a consitent rationale for this navbox, but connfess that it still eludes me. The best I can think of is: it is about "main built-in data types and datatype definition tools provided by the specification of significant programming languages". It must be limited to "built-in" types because otherwise the set is infinite. The types must be provided by the "specification" because the types used in the "implementation" of those languages is also potentially infinte. The "datatype definition tools" are built-in constructs like "record", "array", "reference", that a programmer can use to define other types. Obviously a type that is built-in in one language may be a library type in other; the concept can be defined only relative to a certain set of languages. We must require "bona-fide" languages because weird languages may have very weird data types.

So, coming to the questions: Complex and rational should be listed because there are languages that provide built-in support for them in the syntax, not merely as a library module (including FORTRAN IV, which did not even have records). Intervals are more questionable but they are built-in for Mathematica at least, with standard arithmetic ops.

Finally, on cons cell versus S-expressions: the main data type of LISP is definitely the S-expression. S-expressions are not the same as lists of other languages for many reasons. For instance atoms are a subtype of S-expresions; the CAR and CDR are restricted to have the same data type; the semantics of 'eq' implies that an S-expression can have sharing in both the car and cdr, and it may terminate with an atom other than NIL; etc.

The cons cell is a record type that is used internally in one implementation of the S-expression type. There are other implementations, for example replacing N successive cons-cells by an array with N+1 pointers (N CARs and the last CDR). Admittedly these alternative implementations are not very popular, but they have been serioulsy proposed. Moreover, in pure LISP one cannot have circular lists; that constraint comes naturally with S-expressions, but if cons-cell were the primitive type, then it would be a rather artificial one.

But I am getting tired of this discussion. I do not intend to edit this template any more; I have more productive ways to spend my time. Unfortunately "datatypology" is one of those "philosophical" disciplines where the object of study is mosty in the people's head: one invents arbitrary categories or viewpoints and then spends all the time trying to fit reality into them. Is the tomato a fruit or vegetable? Is Pluto a planet? Are viruses alive? Should integers be viewed as objects? I have wasted enough time already in my life with that sort of inanities... All the best, --Jorge Stolfi (talk) 03:37, 11 May 2009 (UTC)

Bignum is not a data type, but a variant of integer

Bignum is not a distinct type; like short integer and unsigned integer, it is a flavor of integer (computer science) --- and also of floating point, rational data type, interva, etc. All the best, --Jorge Stolfi (talk) 17:33, 10 May 2009 (UTC)

Yes, but it's a unique/distinct flavor of number. One could equally argue that floating-point and fixed-point are mere implementations of Real numbers. --Cybercobra (talk) 01:57, 11 May 2009 (UTC)

But real numbers is a mathematical concept, not a data type. Let's not mix the worlds. No programming language implements a 'real number' data type.

Multi-tiered navbox

Check the navbox at the bottom of carbon monoxide poisoning. If we have to expand this navbox, that may be a good way to do it.

However, the work spent on editing navboxes (-8 and fighting about whether a tomato is a fruit or a vegetable 8-) would be much better spent editing the data type articles themselves --- some are ina very sorry state. All the best, --Jorge Stolfi (talk) 18:35, 10 May 2009 (UTC)

We need a better categorization for the stuff in "other"

Intuitively, some of those are primitive data types, but that article seems hotly contested. Also, first-class function is actually defined using a type constructor (the arrow), so it's not clear that it qualifies as primitive, although this type constructor is built-in with special meaning; but then so are other type constructors like * in product type. We need to look for some refs for terminology; always a big hassle. Pcap ping 05:18, 18 August 2009 (UTC)

Missing types.

Template is missing inductive type and equality type. 99.153.64.179 (talk) 18:47, 26 June 2013 (UTC)

Abstractions over bit(s)

I left single link to bit because previous links were imprecise compared to Template:Information units. It is wrong to keep silent about platform-dependency at Template talk:Data types. Ushkin N (talk) 11:43, 19 July 2016 (UTC)

Timestamp

Just wondered whether timestamp data types should be included in this template? Perhaps that depends on the underlying page being present? But the subpage on digital timestamps should suffice in the interim? HTH. RobbieIanMorrison (talk) 16:04, 23 November 2018 (UTC)