Talk:Primitive type

From Wikipedia, the free encyclopedia

[edit] 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)

[edit] "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)

[edit] 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)