Talk:Primitive type
From Wikipedia, the free encyclopedia
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)
