Talk:Primitive data type

Basic types vs built-in types

I'm a bit uncomfortable with calling first-class functions "primitive types". I think this is confusing two mostly orthogonal concepts: (1) basic types, and (2) built-in types. Either or both are sometimes called "primitive", which is not very helpful.

Re (1): The set of types of most modern programming languages is recursively defined and feature composite types that can be obtained from simpler types. The basic types are the maximally simple types. For example, in C the types int, short, double, etc. are basic. But arrays, pointers, functions are not, since they denote arrays of, pointers to, and function to and from other types. Strings are bit tricky in this regard, since some languages regard them as derived (lists/arrays of characters, as in C) and others regard them as primitive (e.g. Python, which does not have a character type).

Re (2): Built-in types are simply those types with special support from the standard environment of a language. So C has language constructs for array and string literals, and standard library routines for manipulating them (qsort, strcat, etc.). However, that doesn't make arrays primitive types. The array syntax [] in C can be viewed as a unary type constructor, mapping a component type such as int to an array type such as int[] (Java has better syntax for those). Type constructors and types derived from them may be built in, but they are certainly not basic.

Now the question is, what does "primitive" mean anyway? My hunch is that it usually means "basic" (i.e. non-recursive). Java, for example, defines primitive types, but String is not one of them, even though it's built in. --MarkSweep 23:51, 12 Nov 2004 (UTC)

(Eschewing indentation--please feel free to implement if your prefer it) -- Minority Report

I appreciate your discomfort, but I suspect that it's related more to the C-oriented nature of much modern dialog on computing. There are indeed languages in which the primitive datatypes are things that, in C and similar languages, could only be derived in the rather contorted manner you describe. For some languages, a Closure is about as primitive as it gets, however strange that may seem. A closure isn't just some wonderful doohickey that happens to be implemented as a basic type in Lisp or Scheme, it's part of the basic conceptual design of the language. --Minority Report 00:20, 13 Nov 2004 (UTC)

(Ok, we can do this w/o indentation).

Don't get me wrong, I'm all in favor of built-in closures. I just think equating "built-in" and "basic" is misleading. "Built-in" refers to an implementation issue that's language/library specific. You could say that Java has built-in hash maps because there are classes in the standard library that support them; on the other hand Java doesn't have direct language support for hash maps the same way, say, Python does. Regardless, conceptually hash maps, functions/closures, etc. are not basic, since they are recursively defined in terms of other types. It's a map from (type) to (type), and it's a function from (type, type, ...) to (type). Unless a language is completely "untyped" (i.e., there is exactly one type), the set of types is defined recursively in terms of basic types (int, boolean, double, etc.) and rules for deriving non-basic types (int[], functions/maps from booleans to doubles, int*, etc.). It's usually the case that all basic types are built-in types (there are nit-picking exceptions, e.g. Java has a basic null type, namely the type of a literal null, but no syntax for referring to that type). But the converse does clearly not hold, i.e., a language can have built-in composite types, like int[] or double*. So I guess what I'm saying is, distinguish "built-in" from "basic" type; either can be called "primitive", so this article woule be an appropriate place for teasing these things apart. --MarkSweep 00:50, 13 Nov 2004 (UTC)

I agree completely. The whole article was somewhat confused on this point, sometimes using primitive to mean basic, and sometimes using it to mean built-in. I've attempted to fix this. David-Sarah Hopwood (talk) 00:59, 19 December 2008 (UTC)

I'm the guy (Jake in San Diego) who made the edit that says opinions vary on this issue. For instance, IMO, if a built-in type is constructed from other types, it is not a primitive, and it does not matter whether the language developer or the end-user created the type. In this view, one of the primitive types of a C array would be a pointer, and the others would be the primitives that make up the data type of the elements in the array. If C did not have a char type or did not use its code in the construction of a string data type that was native to the language (without including standard libraries), then string would be a primitive. —Preceding unsigned comment added by 76.88.6.105 (talk) 03:52, 31 December 2008 (UTC)

"Values of the primitive types do not share state."

I came across this sentence in the preface to the Java definition. Having no idea what it meant, I searched for it with google. The only other occurrence was on this page, and I still don't know what it means. What is this "state" that primitive variables do not share? What sort of variables do share it, if any? What is its significance? Xarqi (talk) 11:42, 22 February 2008 (UTC)

I added a request for clarification. Maybe related to the lack of pointers in Java? In that sense, primitives CAN share state in other languages. Arosa (talk) 04:23, 9 March 2008 (UTC)

The implication appears to be that two values of a primitive type don't both contain references to some shared substructure - for example, in functional languages it's common for two tree data structures to both contain and refer to the same subtree. Whether this should be part of the definition of a primitive type I'm not really sure - it seems consistent with traditional classification, but is potentially original research. Dcoetzee 20:09, 10 March 2008 (UTC)

Yes, I believe the intent here is explain that assigning the value of one value-type variable to another variable creates a copy of the value as distinguished from a Reference (computer science). But this is really a statement relevant to the idea of "value-type" which really ought to be separate from "primitive-type" as discussed elsewere. Voteformike (talk) 09:08, 21 June 2008 (UTC)

Value Types

Value type redirects here. Value types are not always primitive types. For example, C# allows you to create custom value types, which can be composite. 84.87.183.181 (talk) 10:40, 3 March 2008 (UTC)

Integral type also redirects here. I would suppose that the set of integral types is a subset of primitive types for most languages, but I was hoping for something more directly concerned with the concept of an "integral type". I assume that an integral type is a type such that its value is stored as an integer (such as char, int, and enum in C), but I wanted some clarification. Rainault (talk) 16:43, 18 March 2008 (UTC)

Rainault - you are absolutely right about everything you said. Integer types should not redirect here because all possible integer types are not primitives in all possible languages. (Jake in San Diego). —Preceding unsigned comment added by 76.88.6.105 (talk) 03:57, 31 December 2008 (UTC)

Does this topic deserve a full article?

This article does not seem sufficiently justified. The notion of "primitive type" is quite fuzzy and language-dependent, so there is little that can be said in general about this class that is not better said in the data type article itself. Ditto for composite type. Indeed the distinction between the two is quite debatable; S-expressions for example are a primitive type for LISP but definitely a composite type, and strings in C are just arrays. Methink that primitive type and composite type should be a very short articles, little more than a dictionary entries, with all material moved to data type or other articles. All the best, --Jorge Stolfi (talk) 19:34, 10 May 2009 (UTC)

This page is (bad) original work and does not belong on wikipedia

This should be a blog post or something. The article attempts to lift the definition of "primitive type" from Java as a general term where there is no general usage. Most other languages do not have any concept of "primitive". For languages like C and C where memory layout is semi-manual, the distinction is meaningless. For higher level languages like Python and Haskell where all values are treated equally the distinction is again meaningless. This whole article is taking the hammer of Java terminology and trying to smash all of CS with it. Even C#, the closest language to Java, uses the term primitive in a different way. [[1]]

That page was about Visual Basic, not C#. But I've added it to the built in types section --Mathnerd314159 (talk) 18:24, 18 May 2022 (UTC)

in C, strings are a composite but built-in data type

I would like to question this. I'd say that in C, strings are data objects, not data type. I guess that "type" implies that one could use assignemnt, == comparison etc. to this type. In C, structs are a type. So are arrays. Strings are 8bit ASCII data sequences terminated by '\0'. I would not say that is a type, I'd say that is a data object. By definition, C string "restricts the contents of variable", eg. for strings, last char must be '\0'

--192.100.112.203 (talk) 08:21, 28 September 2011 (UTC)

Definition of primitive

The lead sentence needs a citation. That can't be good. But if the definition becomes salient to the compiler, it might be good? To me a compiler is the prime (primitive) mover (of data) between the mind, with it's conceptual data types and data structures, and the machine; PDTs are the organic chemistry of computation because they are manufactured into everything from memory cells to data structures. I'm thinking they are as important to computation as sets are to math. In fact type theory is fundamental to naive set theory. Product types blend science (math and computation) and art, and so I think the knowledge of primitive data has application of practical (compiler design) and interesting (semiotics) worth, and thus may generate a focused interest. PDTs blend programmers and machines by creating an important type of personal product thing. I think PDT should be defined from the start

In computer science, a primitive data type is a data type a compiler implements that also has semantic significance to the programmer. The machine representation of a primitive data type may vary, while the user-level abstraction remains tied to real-world entities like alphanumeric and data structure conceptualizations. A system to implement primitive data types

— CpiralCpiral 20:44, 29 September 2011 (UTC)

Ranges of integral types in C and C

The C and C standards permit two's complement, ones' complement and signed magnitude representations for integral types. This means that e.g. the range of an 8-bit signed char is required to contain −127 but is not required to contain −128. Should this be mentioned in the table at Primitive data type#Integer numbers or would this be too much detail? – Tea2min (talk) 06:54, 20 September 2018 (UTC)

I have added a corresponding note to the table header. I hope that's OK. – Tea2min (talk) 06:58, 20 September 2018 (UTC)