refers to the ability of a programming language to treat types
(howsoever defined in the language) as first-class entities - in the context of an OO language, for instance, this means that types (classes, etc.) are objects.
Quite a few languages feature FirstClassTypes
, such as:
*excluding lambda, which was purposely underpowered at Guido's insistence BTW.
- SmalltalkLanguage (classes are objects just like any other) classes are not types, and types are not first class objects in Smalltalk, this is a matter of Smalltalk FAQ. When Dave N. Smith maintained the faq, this was mentioned explicitly. (Anybody have a copy? It seems to have disappeared from google.) [There's a draft version at http://ftp.sunet.se/pub/lang/smalltalk/faq/SmallFaqToc.html.] --I beg to disagree with this FAQ, more below--
- RubyLanguage Ruby classes are instances of the class Class.
- PythonLanguage ditto. No, actually, types are real objects. Python even has a type type called (obviously) "type", and casting any object to a type returns its type (ex, type("Hello, world!") -> str). As for functions*, however, GuidoVanRossum decided that it would be easier *not* to have a literal for these.
A few other languages fake it, by introducing a type whose instances are in corresponence with the types in the language, but use/prefer alternate syntax for object creation (no "aClass new" like in Smalltalk).
And in many languages, types are not
first class at all:
Languages without first-class types (or with crippled first-class types) are (roughly speaking), equivalent to the typed LambdaCalculus
(and more advanced theoretical type systems in which objects and types are syntactically different entities). Languages with
true first-class types are (again, roughly speaking) equivalent to the untyped LambdaCalculus
(which makes no distinction). The latter form is more arguably more expressive and elegant (as a syntactic distinction is removed), but suffers from several drawbacks:
- TypeInference is, in general, undecideable. Virtually all languages that have true FirstClassTypes are dynamically typed (Java requires a nest of casts in order to use dynamic object construction).
- You have to be careful of numerous paradoxes that can result from allowing this sort of thing (analogous to the RussellParadox in SetTheory). Languages with FirstClassTypes can generally constrain their type systems such that paradoxes don't occur - or else (since you have to use DynamicTyping anyway) use DuckTyping everywhere and not bother with formal type judgements.
For more excitement, check out dependently typed languages (like EpigramLanguage?
), where types and functions are almost exactly the same thing, and both are first class.
This gets you neat features like being able to check the length of a list by its type, and .. well you can just think of the many neat things you could do if a type could be described by any amount of code. -- ShaeErisson
- classes are not types, and types are not first class objects in Smalltalk, this is a matter of Smalltalk FAQ. When Dave N. Smith maintained the faq, this was mentioned explicitly. (Anybody have a copy? It seems to have disappeared from google.) [There's a draft version at http://ftp.sunet.se/pub/lang/smalltalk/faq/SmallFaqToc.html.]
The cited FAQ goes to explain how variables have no type. But Scheme (to name just one very "typeful" DynamicTypedLanguage?
) has no types for variables
, but it has a very defined TypeSystem
. It confuses DynamicTyping
. It takes this confusion further on: it says that the "claim" that classes are Smalltalk types is "an especially dangerous redefinition" of the concept of type, "from a characteristic of a variable to a characteristic of data".
Type IS a characteristic of data, as it states the way data should be interpreted. Type says "this run of bits here represent a float" and "this bytes here are a representation of a tree".
You can attach type to a variable, or data itself. If you attach it to variables, you have something like CeeLanguage
.If you attach it to the data itself, you (may) have a DynamicTyping
language. If you additionally pack it with operations on that data, then how is it different from classes? --fs.
Ok. Giving some more thought to it. I think classes behave for all intents like types. They:
- State valid semantics and operations
- Allow for classification of data
- Provide means of subtyping (an integer is also a number)
- Provide means of composition
- Allow for arbitrary equivalences between disjoint types (an Array2D may not be a Collection subclass, because Collection presumes 1 dimension, but still implement part of the interface).
If they're still not real types, that's something you'll probably never care, anyway.