FirstClassTypes 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:
- 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
--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.
*excluding lambda, which was purposely underpowered at Guido's insistence BTW.
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).
- JavaLanguage (you can use getConstructor(types).newInstance(args) to make new instances from a Class object, but it's a pain in the class to do so).
- CeeSharpLanguage is similar using the Reflection system, and is even powerful enough to generate new types. CeeSharp's types are generally true first-class-objects, but trapped in a horrible syntax of typecasts, static methods, and other ugliness. However, this functionality is handy in .NET languages that are friendlier to dynamic types. See
- EiffelLanguage
- CeePlusPlus with RunTimeTypeInformation (the type_id class) fakes it very badly.
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
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 vs
StaticTyping. 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
They also:
- 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.
First Class Types