|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| {{about|type systems from the point-of-view of computer programming|a theoretical formulation|type theory}}
| | Nothing to say about myself I think.<br>Finally a part of wmflabs.org.<br>I just wish I am useful at all<br><br>Review my blog post - [http://hemorrhoidtreatmentfix.com/hemorrhoid-symptoms hemorrhoids symptoms] |
| {{More footnotes| date=October 2010}}
| |
| {{Type systems}}
| |
| In [[programming language]]s, a '''type system''' is a collection of rules that assign a property called a ''[[type (computer science)|type]]'' to the various constructs—such as [[variable (computer science)|variable]]s, [[expression (computer science)|expression]]s, [[function (computer science)|function]]s or [[module (computer science)|module]]s—a [[computer program]] is composed of.{{sfn|Pierce|2002|p=1|ps=: "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute."}} The main purpose of a type system is to reduce [[bug (computer programming)|bug]]s in computer programs{{sfn|Cardelli|2004|p=1|ps=: "The fundamental purpose of a type system is to prevent the occurrence of ''execution errors'' during the running of a program."}} by defining interfaces between different parts of a computer program, and then checking that the parts have been connected in a consistent way. This checking can happen statically (at [[compile time]]), dynamically (at [[run time (program lifecycle phase)|run time]]), or it can happen as a a combination of static and dynamic checking.
| |
| | |
| An example of a simple type system is that of the [[C (programming language)|C language]]. The portions of a C program are the [[Subroutine|function]] definitions. One function is invoked by another function. The interface of a function states the name of the function and a list of values that are passed to the function's code. The code of an invoking function states the name of the invoked, along with the names of variables that hold values to pass to it. During execution, the values are placed into temporary storage, then execution jumps to the code of the invoked function. The invoked function's code accesses the values and makes use of them. If the instructions inside the function are written with the assumption of receiving an integer value, but the calling code passed a floating-point value, then the wrong result will be computed by the invoked function. The C compiler checks the type declared for each variable sent, against the type declared for each variable in the interface of the invoked function. If the types do not match, the compiler throws a compile-time error.
| |
| | |
| In greater technical depth, a type-system associates a ''[[datatype|type]]'' with each computed value. By examining the flow of these values, a type system attempts to ensure or prove that no ''[[type error]]s'' can occur. The particular type system in question determines exactly what constitutes a type error, but in general the aim is to prevent operations expecting a certain kind of value from being used with values for which that operation does not make sense ([[logic error]]s); [[memory error]]s will also be prevented. Type systems are often specified as part of [[programming language]]s, and built into the interpreters and compilers for them; although the type system of a language can be extended by [[extended static checking|optional tools]] that perform additional kinds of checks using the language's original type syntax and grammar.
| |
| | |
| A [[compiler]] may also use the static type of a value to optimize the storage it needs and the choice of algorithms for operations on the value. In many [[C (programming language)|C]] compilers the ''float'' [[data type]], for example, is represented in 32 [[bit]]s, in accord with the [[IEEE 754-2008|IEEE specification for single-precision floating point numbers]]. They will thus use floating-point-specific [[instruction set|microprocessor operations]] on those values (floating-point addition, multiplication, etc.).
| |
| | |
| The depth of type constraints and the manner of their evaluation affect the ''typing'' of the language. A [[programming language]] may further associate an operation with varying concrete algorithms on each type in the case of [[type polymorphism]]. [[Type theory]] is the study of type systems, although the concrete type systems of programming languages originate from practical issues of computer architecture, compiler implementation, and language design.
| |
| | |
| ==Fundamentals==
| |
| Formally, [[type theory]] studies type systems. A programming language must have occurrence to type check using the ''type system'' whether at compiler time or runtime, manually annotated or automatically inferred. As [[Mark Manasse]] concisely put it:{{sfn|Pierce|2002|p=208}}
| |
| {{quote|The fundamental problem addressed by a type theory is to ensure that programs have meaning. The fundamental problem caused by a type theory is that meaningful programs may not have meanings ascribed to them. The quest for richer type systems results from this tension.}}
| |
| | |
| Assigning a data type, what is called ''typing'', gives meaning to a sequences of [[bit]]s such as a value in [[computer memory|memory]] or some [[object (computer science)|object]] such as a [[variable (computer science)|variable]]. The hardware of a [[general purpose computer]] is unable to discriminate between for example a [[memory address]] and an [[instruction code (programming)|instruction code]], or between a [[character (computing)|character]], an [[integer]], or a [[floating-point number]], because it makes no intrinsic distinction between any of the possible values that a sequence of bits might ''mean''. Associating a sequence of bits with a type conveys that [[wikt:meaning|meaning]] to the programmable hardware to form a ''[[symbolic system]]'' composed of that hardware and some program.
| |
| | |
| <!--===Richness evolves===--> | |
| A program associates each value with at least one particular type, but it also can occur that one value is associated with many [[subtype]]s. Other entities, such as [[object (computer science)|objects]], [[module (programming)|modules]], communication channels, [[dependency (computer science)|dependencies]] can become associated with a type. Even a type can become associated with a type. An implementation of some ''type system'' could in theory associate some identifications named this way:
| |
| * [[data type]] – a type of a value
| |
| * [[class (computer science)|class]] – a type of an object
| |
| * [[kind (type theory)]] – a ''type of a type'', or metatype
| |
| These are the kinds of abstractions typing can go through on a hierarchy of levels contained in a system.
| |
| | |
| When a programming language evolves a more elaborate type system, it gains a more finely-grained rule set than basic type checking, but this comes at a price when the type inferences (and other properties) become [[undecidable problem|undecidable]], and when more attention must be paid by the programmer to annotate code or to consider computer-related operations and functioning. It is challenging to find a sufficiently expressive type system that satisfies all programming practices in a [[type safe]] manner.
| |
| | |
| The more type restrictions that are imposed by the compiler, the more ''strongly typed'' a programming language is. Strongly typed languages often require the programmer to make explicit conversions in contexts where an implicit conversion would cause no harm. Pascal's type system has been described as "too strong" because, for example, the size of an array or string is part of its type, making some programming tasks difficult.<ref>[http://books.google.co.uk/books?id=7i8EAAAAMBAJ&pg=PA66&lpg=PA66&dq=pascal+type+system+%22too+strong%22&source=bl&ots=PGyKS1fWUb&sig=ebFI6fk_yxwyY4b7sHSklp048Q4&hl=en&ei=lSmjTunuBo6F8gPOu43CCA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBsQ6AEwAA#v=onepage&q=pascal%20type%20system%20%22too%20strong%22&f=false Infoworld 25 April 1983]</ref><ref>[http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html [[Brian Kernighan]]: ''Why Pascal is not my favorite language'']</ref> [[Haskell (programming language)|Haskell]] is also strongly typed but its types are automatically inferred so that explicit conversions are unnecessary.
| |
| | |
| A programming language compiler can also implement a ''[[dependent type]]'' or an ''[[effect system]]'', which enables even more program specifications to be verified by a type checker. Beyond simple value-type pairs, a virtual "region" of code is associated with an "effect" component describing ''what'' is being done ''with what'', and enabling for example to "throw" an error report. Thus the symbolic system may be a ''type and effect system'', which endows it with more safety checking than type checking alone.
| |
| | |
| <!--===Advantages sustain===-->
| |
| Whether automated by the compiler or specified by a programmer, a type system makes program behavior illegal that is outside the type-system rules. Advantages provided by programmer-specified type systems include:
| |
| * ''Abstraction'' (or ''modularity'') – Types enable programmers to think at a higher level than the bit or byte, not bothering with low-level implementation. For example, programmers can begin to think of a string as a collection of character values instead of as a mere array of bytes. Higher still, types enable programmers to think about and express [[interface (computer science)|interface]]s between two of ''any''-sized subsystems. This enables more levels of localization so that the definitions required for interoperability of the subsystems remain consistent when those two subsystems communicate.
| |
| * ''Documentation'' – In more expressive type systems, types can serve as a form of [[documentation]] clarifying the intent of the programmer. For instance, if a programmer declares a function as returning a timestamp type, this documents the function when the timestamp type can be explicitly declared deeper in the code to be integer type.
| |
| | |
| Advantages provided by compiler-specified type systems include:
| |
| * ''Optimization'' – Static type-checking may provide useful compile-time information. For example, if a type requires that a value must align in memory at a multiple of four bytes, the compiler may be able to use more efficient machine instructions.
| |
| * ''Safety'' – A type system enables the [[compiler]] to detect meaningless or probably invalid code. For example, we can identify an expression <code>3 / "Hello, World"</code> as invalid, when the rules do not specify how to divide an [[integer]] by a [[string (computer science)|string]]. Strong typing offers more safety, but cannot guarantee complete ''[[type safety]]''.
| |
| | |
| Type safety contributes to [[program correctness]], but can only guarantee correctness at the expense of making the type checking itself an [[undecidable problem]]. In a ''type system'' with automated type checking a program may prove to run incorrectly yet be safely typed, and produce no compiler errors. Division by zero is an unsafe and incorrect operation, but a type checker running only at [[compile time]] doesn't scan for [[division by zero]] in most programming languages, and then it is left as a [[runtime error]]. To prove the absence of these more-general-than-types defects, other kinds of [[formal method]]s, collectively known as [[program analysis (computer science)|program analyses]], are in common use. In addition [[software testing]] is an [[empirical]] method for finding errors that the type checker cannot detect.
| |
| | |
| ==Type checking==
| |
| The process of verifying and enforcing the constraints of types – ''type checking'' – may occur either at [[compile-time]] (a static check) or [[Run time (program lifecycle phase)|run-time]] (a dynamic check). If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions that do not lose information), one can refer to the process as ''strongly typed'', if not, as ''weakly typed''. The terms are not usually used in a strict sense.
| |
| | |
| ===Static type-checking===
| |
| Static type-checking is the process of verifying the type safety of a program based on analysis of a program's text (source code). If a program passes a static type-checker, then the program is guaranteed to satisfy some set of type-safety properties for all possible inputs.
| |
| | |
| Because static type-checking operates on a program's text, it allows many bugs to be [[fail-fast|caught early]] in the development cycle.
| |
| | |
| Static type-checking can be thought of as a limited form of [[program verification]] (see [[type safety]]). In a type-safe language, static type-checking can also be thought of as an optimization. If a compiler can prove that a program is well-typed, then it does not need to emit dynamic safety checks, allowing the resulting compiled binary to run faster.
| |
| | |
| Static type-checking for Turing-complete languages is inherently conservative. That is, if a type system is both ''sound'' (meaning that it rejects all incorrect programs) and ''decidable'' (meaning that it is possible to write an algorithm which determines whether a program is well-typed), then it will always be possible to define a program which is well-typed but which does not satisfy the type-checker.<ref>{{cite web|last=R´emy|first=Didier|title=Type systems for programming languages|url=http://gallium.inria.fr/~remy/mpri/cours1.pdf|accessdate=26 May 2013}}</ref> For example, consider a program containing the code:
| |
| | |
| <code>if <complex test> then <do something> else <type error></code>
| |
| | |
| Even if the expression <code><complex test></code> always evaluates to <code>true</code> at run-time, most type-checkers will reject the program as ill-typed, because it is difficult (if not impossible) for a static analyzer to determine that the <code>else</code> branch will not be taken.{{sfn|Pierce|2002}} Conversely, a static type-checker will quickly detect type errors in rarely-used code paths. Without static type checking, even [[code coverage]] tests with 100% coverage may be unable to find such type errors. The tests may fail to detect such type errors, because the combination of all places where values are created and all places where a certain value is used must be taken into account.
| |
| | |
| A number of useful and common programming language features cannot be checked statically, such as [[downcasting]]. Therefore, many languages will have both static and dynamic type-checking; the static type-checker verifies what it can, and dynamic checks verify the rest.
| |
| | |
| Many languages with static type-checking provide a way to bypass the type checker. Some languages allow programmers to choose between static and dynamic type safety. For example, [[C Sharp (programming language)|C#]] distinguishes between "statically-typed" and "dynamically-typed" variables; uses of the former are checked statically, while uses of the latter are checked dynamically. Other languages allow users to write code which is not type-safe. For example, in [[C (programming language)|C]], programmers can freely cast a value between any two types which have the same size.
| |
| | |
| For a list of languages with static type-checking, see [[:Category:Statically typed programming languages|the category for statically typed languages]].
| |
| | |
| === Dynamic type-checking and runtime type information === <!-- the redirect [[Dynamic typing]] points here, so if you change the title, change the redirect, too -->
| |
| | |
| Dynamic type-checking is the process of verifying the type safety of a program at runtime. Implementations of dynamically type-checked languages generally associate runtime objects with "tags" containing their type information. This runtime type information (RTTI) can also be used to implement [[dynamic dispatch]], [[late binding]], [[downcasting]], [[Reflection (computer programming)|reflection]], and similar features.
| |
| | |
| Most type-safe languages include some form of dynamic type-checking, even if they also have a static type checker. The reason for this is that many useful features or properties are difficult or impossible to verify statically. For example, suppose that a program defines two types, A and B, where B is a subtype of A. If the program tries to convert a value of type A to type B, then the operation is legal only if the value being converted is actually a value of type B. Therefore, a dynamic check is needed to verify that the operation is safe.
| |
| | |
| By definition, dynamic type-checking may cause a program to fail at runtime. In some programming languages, it is possible to anticipate and recover from these failures. In others, type-checking errors are considered fatal.
| |
| | |
| Programming languages which include dynamic type-checking but not static type-checking are often called "dynamically-typed programming languages". For a list of such languages, see [[:Category:Dynamically typed programming languages|the category for dynamically typed programming languages]].
| |
| | |
| ===Combining static and dynamic type-checking===
| |
| The presence of static type-checking in a programming language does not necessarily imply the absence of dynamic type-checking. For example, Java and some other ostensibly statically typed languages support [[downcasting]] types to their [[subtypes]], querying an object to discover its dynamic type and other type operations that depend on runtime type information. More generally, most programming languages include mechanisms for dispatching over different 'kinds' of data, such as [[disjoint union]]s, [[polymorphism in object-oriented programming|subtype polymorphism]], and [[variant type]]s. Even when not interacting with type annotations or type checking, such mechanisms are materially similar to dynamic typing implementations. See [[programming language]] for more discussion of the interactions between static and dynamic typing.
| |
| | |
| Objects in object oriented languages are usually accessed by a reference whose static target type (or manifest type) is equal to either the object's run-time type (its latent type) or a supertype thereof. This is conformant with the [[Liskov substitution principle]] that states that all operations performed on an instance of a given type can also be performed on an instance of a subtype. This concept is also known as [[subsumption]]. In some languages subtypes may also possess [[Covariance and contravariance (computer science)|covariant or contravariant]] return types and argument types respectively.
| |
| | |
| Certain languages, for example [[Clojure]], [[Common Lisp]], or [[Cython]], are dynamically type-checked by default, but allow programs to opt into static type-checking by providing optional annotations. One reason to use such hints would be to optimize the performance of critical sections of a program.
| |
| | |
| As of version 4.0, the C# language provides a way to indicate that a variable should not be statically type-checked. A variable whose type is <code>dynamic</code> will not be subject to static type-checking. Instead, the program relies on runtime type information to determine how the variable may be used.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/dd264741.aspx|title=dynamic (C# Reference)|work=[[MSDN Library]]|publisher=Microsoft|accessdate=14 January 2014}}</ref>
| |
| | |
| ===Static and dynamic type checking in practice===
| |
| The choice between static and dynamic typing requires [[trade-off]]s.
| |
| | |
| Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus disagree over the proportion of those bugs that are coded that would be caught by appropriately representing the designed types in code. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of [[dependent type|dependently typed languages]] such as [[Dependent ML]] and [[Epigram (programming language)|Epigram]] have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.<ref>{{Cite journal
| |
| |last1=Xi
| |
| |first1=Hongwei
| |
| |last2=Scott
| |
| |first2=Dana
| |
| |title=Dependent Types in Practical Programming
| |
| |journal=Proceedings of ACM SIGPLAN Symposium on Principles of Programming Languages
| |
| |year=1998
| |
| |pages=214–227
| |
| |publisher=ACM Press
| |
| |id = {{citeseerx|10.1.1.41.548}} }}</ref>
| |
| | |
| Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as [[Common Lisp]] allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See [[optimization (computer science)|optimization]].
| |
| | |
| By contrast, dynamic typing may allow compilers to run more quickly and allow [[Language interpretation|interpreters]] to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.
| |
| | |
| Statically typed languages that lack [[type inference]] (such as C and Java) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include [[Haskell (programming language)|Haskell]], [[Scala (programming language)|Scala]], [[OCaml (programming language)|OCaml]], [[F Sharp (programming language)|F#]] and to a lesser extent [[C Sharp (programming language)|C#]]), so explicit type declaration is not a necessary requirement for static typing in all languages.
| |
| | |
| Dynamic typing allows constructs that some static type checking would reject as illegal. For example, ''[[eval]]'' functions, which execute arbitrary data as code, become possible. An ''eval'' function is possible with static typing, but requires advanced uses of [[GADT|algebraic data types]]. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure ([[mock object]]) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).
| |
| | |
| Dynamic typing typically allows [[duck typing]] (which enables [[duck typing#Comparison with other type systems|easier code reuse]]). Many languages with static typing also feature [[duck typing#In statically typed languages|duck typing]] or other mechanisms like [[generic programming]] which also enables easier code reuse.
| |
| | |
| Dynamic typing typically makes [[metaprogramming]] easier to use. For example, [[C++]] [[template (programming)|templates]] are typically more cumbersome to write than the equivalent [[Ruby (programming language)|Ruby]] or [[Python (programming language)|Python]] code. More advanced run-time constructs such as [[metaclass]]es and [[introspection (computer science)|introspection]] are often more difficult to use in statically typed languages. In some languages, such features may also be used e.g. to generate new types and behaviors on the fly, based on run-time data. Such advanced constructs are often provided by [[dynamic programming language]]s; many of these are dynamically typed, although ''dynamic typing'' need not be related to ''dynamic programming languages''.
| |
| | |
| ==="Strong" and "weak" type systems===
| |
| {{Main|Strong and weak typing}}
| |
| | |
| Languages are often colloquially referred to as "strongly typed" or "weakly typed". In fact, there is no universally accepted definition of what these terms mean. In general, there are more precise terms to represent the differences between type systems that lead people to call them "strong" or "weak".
| |
| | |
| ===Type safety and memory safety ===<!-- This section is linked from [[Java (programming language)]] -->
| |
| {{Main|Type safety}}
| |
| A third way of categorizing the type system of a programming language uses the safety of typed operations and conversions. Computer scientists consider a language "type-safe" if it does not allow operations or conversions that violate the rules of the type system.
| |
| | |
| Some observers use the term ''memory-safe language'' (or just ''safe language'') to describe languages that do not allow programs to access memory that has not been assigned for their use. For example, a memory-safe language will [[bounds checking|check array bounds]], or else statically guarantee (i.e., at compile time before execution) that array accesses out of the array boundaries will cause compile-time and perhaps runtime errors.
| |
| | |
| Consider the following program of a language that is both type-safe and memory-safe:<ref>[[Visual Basic]] is an example of a language that is both type-safe and memory-safe.</ref>
| |
| | |
| <source lang=text line>
| |
| var x := 5;
| |
| var y := "37";
| |
| var z := x + y;
| |
| </source>
| |
| | |
| In this example, the variable {{code|z}} will have the value 42. While this may not be what the programmer anticipated, it is a well-defined result. If {{code|y}} was a different string, one that could not be converted to a number (e.g. "Hello World"), the result would be well-defined as well. Note that a program can be type-safe or memory-safe and still crash on an invalid operation; in fact, if a program encounters an operation which is not type-safe, terminating the program is often the only option.
| |
| | |
| Now consider a similar example in C:
| |
| | |
| <source lang=C line>
| |
| int x = 5;
| |
| char y[] = "37";
| |
| char* z = x + y;
| |
| </source>
| |
| | |
| In this example {{C-lang|z}} will point to a memory address five characters beyond {{C-lang|y}}, equivalent to three characters after the terminating zero character of the string pointed to by {{C-lang|y}}. This is memory that the program is not expected to access. It may contain garbage data, and it certainly doesn't contain anything useful. As this example shows, C is neither a memory-safe nor a type-safe language.
| |
| | |
| In general, type-safety and memory-safety go hand in hand. For example, a language which supports pointer arithmetic and number-to-pointer conversions (like C) is neither memory-safe nor type-safe, since it allows arbitrary memory to be accessed as if it were valid memory of any type.
| |
| | |
| For more information, see [[memory safety]].
| |
| | |
| ===Variable levels of type checking===
| |
| | |
| Some languages allow different levels of checking to apply to different regions of code. Examples include:-
| |
| * The <code>use strict</code> directive in [[javascript]]<ref>[http://www.ecma-international.org/publications/standards/Ecma-262.htm Standard ECMA-262]. Ecma-international.org. Retrieved on 2013-07-17.</ref><ref>[https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode Strict mode - JavaScript | MDN]. Developer.mozilla.org (2013-07-03). Retrieved on 2013-07-17.</ref><ref>[http://msdn.microsoft.com/en-us/library/ie/br230269(v=vs.94).aspx Strict Mode (JavaScript)]. Msdn.microsoft.com. Retrieved on 2013-07-17.</ref> and [[Perl]] applies stronger checking.
| |
| * The <code>@</code> operator in [[PHP]] suppresses some error messages.
| |
| * The <code lang="vb">Option Strict On</code> in [[VB.NET]] allows the compiler to require a conversion between objects.
| |
| | |
| Additional tools such as [[lint (software)|lint]] and [[IBM Rational Purify]] can also be used to achieve a higher level of strictness.
| |
| | |
| ===Optional type systems===
| |
| | |
| It has been proposed, chiefly by [[Gilad Bracha]], that the choice of type system be made independent of choice of language; that a type system should be a module that
| |
| can be "plugged" into a language as required. He believes this is advantageous, because what he calls mandatory type systems make languages less expressive and code more fragile.<ref>[http://bracha.org/pluggableTypesPosition.pdf Bracha, G.: ''Pluggable Types'']</ref> The requirement that types do not affect the semantics of the language is difficult to fulfill: for instance, class based inheritance becomes impossible.
| |
| | |
| ==Polymorphism and types==
| |
| {{Main|Polymorphism (computer science)}}
| |
| The term "polymorphism" refers to the ability of code (in particular, methods or classes) to act on values of multiple types, or to the ability of different instances of the same data structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an [[associative array]] once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism ''[[generic programming]]''. The type-theoretic foundations of polymorphism are closely related to those of [[abstraction (computer science)|abstraction]], [[module (programming)|modularity]] and (in some cases) [[subtype|subtyping]].
| |
| | |
| ===Duck typing===
| |
| {{Main|Duck typing}}
| |
| In "duck typing",<ref>{{Cite doi|10.1145.2F1266894.1266904}}</ref>
| |
| a statement calling a [[method (computer science)|method]] <code>m</code> on an object does not rely on the declared type of the object; only that the object, of whatever type, must supply an implementation of the method called, when called, at run-time.
| |
| | |
| Duck typing differs from [[structural type system|structural typing]] in that, if the ''part'' (of the whole module structure) needed for a given local computation is present ''at runtime'', the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile time to determine type identity or type dependence.
| |
| | |
| Duck typing differs from a [[nominative type system]] in a number of aspects. The most prominent ones are that for duck typing, type information is determined at runtime (as contrasted to compile time), and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that for a given point in the program execution.
| |
| | |
| Duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck" (this is a reference to the [[duck test]] that is attributed to [[James Whitcomb Riley]]). The term may have been coined {{Citation needed|date=January 2011}} by [[Alex Martelli]] in a 2000 message<ref>{{cite newsgroup
| |
| |title=Re: polymorphism (was Re: Type checking in python?)
| |
| |author=Martelli, Alex
| |
| |id=8lmvn6017l@news1.newsguy.com
| |
| |date=26 July 2000
| |
| |url=http://groups.google.com/group/comp.lang.python/msg/e230ca916be58835?hl=en&}}</ref> to the comp.lang.python [[newsgroup]] (see [[Python (programming language)|Python]]).
| |
| | |
| Duck typing has been demonstrated to increase programmer productivity in a controlled experiment.<ref>Stefan Hanenberg. ”An experiment about static and dynamic type systems: doubts about the positive impact of static type systems on development time“. OOPSLA 2010.</ref>{{failed verification|Source concludes they found no positive or negative effect of using a static type system; does not mention duck typing.|date=December 2012}}
| |
| | |
| ==Specialized type systems==
| |
| Many type systems have been created that are specialized for use in certain environments with certain types of data, or for out-of-band [[static program analysis]]. Frequently, these are based on ideas from formal [[type theory]] and are only available as part of prototype research systems.
| |
| | |
| ===Dependent types===
| |
| [[Dependent type]]s are based on the idea of using scalars or values to more precisely describe the type of some other value. For example, <math>matrix(3, 3)</math> might be the type of a 3×3 matrix. We can then define typing rules such as the following rule for matrix multiplication:
| |
| | |
| <math>matrix_{multiply} : matrix(k, m) \times matrix(m, n) \to matrix(k, n)</math>
| |
| | |
| where <math>k</math>, <math>m</math>, <math>n</math> are arbitrary positive integer values. A variant of [[ML (programming language)|ML]] called [[Dependent ML]] has been created based on this type system, but because type checking for conventional dependent types is [[decidable set|undecidable]], not all programs using them can be type-checked without some kind of limits. Dependent ML limits the sort of equality it can decide to [[Presburger arithmetic]].
| |
| | |
| Other languages such as [[Epigram (programming language)|Epigram]] make the value of all expressions in the language decidable so that type checking can be decidable. However, in general [[Halting Problem|proof of decidability is undecidable]], so many programs require hand-written annotations, which may be very non-trivial. As this impedes the development process many language implementations provide an easy way out in the form of an option to disable this condition. This, however, comes at the cost of making the type-checker run in an [[infinite loop]] when fed programs that don't type-check, causing the compiler to hang.
| |
| | |
| ===Linear types===
| |
| [[Linear type]]s, based on the theory of [[linear logic]], and closely related to [[uniqueness type]]s, are types assigned to values having the property that they have one and only one reference to them at all times. These are valuable for describing large [[immutable value]]s such as files, strings, and so on, because any operation that simultaneously destroys a linear object and creates a similar object (such as '<code>str = str + "a"</code>') can be optimized "under the hood" into an in-place mutation. Normally this is not possible, as such mutations could cause side effects on parts of the program holding other references to the object, violating [[referential transparency (computer science)|referential transparency]]. They are also used in the prototype operating system [[Singularity (operating system)|Singularity]] for interprocess communication, statically ensuring that processes cannot share objects in shared memory in order to prevent race conditions. The [[Clean (programming language)|Clean]] language (a [[Haskell (programming language)|Haskell]]-like language) uses this type system in order to gain a lot of speed{{Nonspecific|date=June 2011}} while remaining safe.
| |
| | |
| ===Intersection types===
| |
| [[Intersection type]]s are types describing values that belong to ''both'' of two other given types with overlapping value sets. For example, in most implementations of C the signed char has range -128 to 127 and the unsigned char has range 0 to 255, so the intersection type of these two types would have range 0 to 127. Such an intersection type could be safely passed into functions expecting ''either'' signed or unsigned chars, because it is compatible with both types.
| |
| | |
| Intersection types are useful for describing overloaded function types: For example, if "{{C-lang|int}} → {{C-lang|int}}" is the type of functions taking an integer argument and returning an integer, and "{{C-lang|float}} → {{C-lang|float}}" is the type of functions taking a float argument and returning a float, then the intersection of these two types can be used to describe functions that do one or the other, based on what type of input they are given. Such a function could be passed into another function expecting an "{{C-lang|int}} → {{C-lang|int}}" function safely; it simply would not use the "{{C-lang|float}} → {{C-lang|float}}" functionality.
| |
| | |
| In a subclassing hierarchy, the intersection of a type and an ancestor type (such as its parent) is the most derived type. The intersection of sibling types is empty.
| |
| | |
| The Forsythe language includes a general implementation of intersection types. A restricted form is [[refinement type]]s.
| |
| | |
| ===Union types===
| |
| [[Union type]]s are types describing values that belong to ''either'' of two types. For example, in C, the signed char has range -128 to 127, and the unsigned char has range 0 to 255, so the union of these two types would have range -128 to 255. Any function handling this union type would have to deal with integers in this complete range. More generally, the only valid operations on a union type are operations that are valid on ''both'' types being unioned. C's "union" concept is similar to union types, but is not typesafe, as it permits operations that are valid on ''either'' type, rather than ''both''. Union types are important in program analysis, where they are used to represent symbolic values whose exact nature (e.g., value or type) is not known.
| |
| | |
| In a subclassing hierarchy, the union of a type and an ancestor type (such as its parent) is the ancestor type. The union of sibling types is a subtype of their common ancestor (that is, all operations permitted on their common ancestor are permitted on the union type, but they may also have other valid operations in common).
| |
| | |
| ===Existential types===
| |
| [[existential quantifier|Existential]] types are frequently used in connection with [[record type]]s to represent [[module (programming)|module]]s and [[abstract data type]]s, due to their ability to separate implementation from interface. For example, the type "T = ∃X { a: X; f: (X → int); }" describes a module interface that has a data member named ''a'' of type ''X'' and a function named ''f'' that takes a parameter of the ''same'' type ''X'' and returns an integer. This could be implemented in different ways; for example:
| |
| | |
| * intT = { a: int; f: (int → int); }
| |
| * floatT = { a: float; f: (float → int); }
| |
| | |
| These types are both subtypes of the more general existential type T and correspond to concrete implementation types, so any value of one of these types is a value of type T. Given a value "t" of type "T", we know that "t.f(t.a)" is well-typed, regardless of what the abstract type ''X'' is. This gives flexibility for choosing types suited to a particular implementation while clients that use only values of the interface type—the existential type—are isolated from these choices.
| |
| | |
| In general it's impossible for the typechecker to infer which existential type a given module belongs to. In the above example intT { a: int; f: (int → int); } could also have the type ∃X { a: X; f: (int → int); }. The simplest solution is to annotate every module with its intended type, e.g.:
| |
| | |
| * intT = { a: int; f: (int → int); } '''as''' ∃X { a: X; f: (X → int); }
| |
| | |
| Although abstract data types and modules had been implemented in programming languages for quite some time, it wasn't until 1988 that [[John C. Mitchell]] and [[Gordon Plotkin]] established the formal theory under the slogan: "Abstract [data] types have existential type".<ref>Mitchell, John C.; Plotkin, Gordon D.; [http://theory.stanford.edu/~jcm/papers/mitch-plotkin-88.pdf ''Abstract Types Have Existential Type''], ACM Transactions on Programming Languages and Systems, Vol. 10, No. 3, July 1988, pp. 470–502</ref> The theory is a second-order [[typed lambda calculus]] similar to [[System F]], but with existential instead of universal quantification.
| |
| | |
| ==Explicit or implicit declaration and inference==
| |
| {{details|Type inference}}
| |
| Many static type systems, such as those of C and Java, require ''type declarations'': The programmer must explicitly associate each variable with a particular type. Others, such as Haskell's, perform ''[[type inference]]'': The compiler draws conclusions about the types of variables based on how programmers use those variables. For example, given a function {{Java|f(x, y)}} that adds {{Java|x}} and {{Java|y}} together, the compiler can infer that {{Java|x}} and {{Java|y}} must be numbers – since addition is only defined for numbers. Therefore, any call to {{Java|f}} elsewhere in the program that specifies a non-numeric type (such as a string or list) as an argument would signal an error.
| |
| | |
| Numerical and string constants and expressions in code can and often do imply type in a particular context. For example, an expression {{Java|3.14}} might imply a type of [[floating-point]], while {{Java|[1, 2, 3]}} might imply a list of integers – typically an [[array data structure|array]].
| |
| | |
| Type inference is in general possible, if it is [[decidability (logic)|decidable]] in the type theory in question. Moreover, even if inference is undecidable in general for a given type theory, inference is often possible for a large subset of real-world programs. Haskell's type system, a version of [[type inference#Hindley–Milner type inference algorithm|Hindley-Milner]], is a restriction of [[System F-omega|System Fω]] to so-called rank-1 polymorphic types, in which type inference is decidable. Most Haskell compilers allow arbitrary-rank polymorphism as an extension, but this makes type inference undecidable. (Type checking is decidable, however, and rank-1 programs still have type inference; higher rank polymorphic programs are rejected unless given explicit type annotations.)
| |
| | |
| ==Types of types==
| |
| {{Main|Data type}}
| |
| A ''type of types'' is a [[kind (type theory)|kind]]. Kinds appear explicitly in [[typeful programming]], such as a ''type constructor'' in the [[Haskell (programming language)|Haskell]] language.
| |
| | |
| Types fall into several broad categories:
| |
| * [[Primitive type]]s – the simplest kind of type; e.g., [[integer]] and [[floating-point number]]
| |
| ** [[Boolean data type|Boolean]]
| |
| ** [[Integral type]]s – types of whole numbers; e.g., integers and natural numbers
| |
| ** [[Floating point type]]s – types of numbers in [[floating-point]] representation
| |
| * [[Reference type]]s
| |
| * [[Option type]]s
| |
| ** [[Nullable type]]s
| |
| * [[Composite type]]s – types composed of basic types; e.g., [[array data structure|arrays]] or [[record (computer science)|records]].
| |
| *:[[Abstract data type]]s
| |
| * [[Algebraic types]]
| |
| * [[Subtype]]
| |
| * [[derived class|Derived type]]
| |
| * [[Object type]]s; e.g., [[type variable]]
| |
| * [[Partial type]]
| |
| * [[Recursive type]]
| |
| * [[Function type]]s; e.g., binary functions
| |
| * [[universal quantification|universally quantified]] types, such as parameterized types
| |
| * [[existential quantification|existentially quantified]] types, such as [[module (programming)|modules]]
| |
| * [[Refinement type]]s – types that identify subsets of other types
| |
| * [[Dependent type]]s – types that depend on terms (values)
| |
| * [[Ownership type]]s – types that describe or constrain the structure of object-oriented systems
| |
| * Pre-defined types provided for convenience in real-world applications, such as date, time and money.
| |
| | |
| ==Unified type system==
| |
| Some languages like [[C Sharp (programming language)|C#]] have a unified type system.<ref>[http://www.ecma-international.org/publications/standards/Ecma-334.htm Standard ECMA-334], 8.2.4 Type system unification.</ref> This means that all [[C Sharp (programming language)|C#]] types including primitive types inherit from a single root object. Every type in [[C Sharp (programming language)|C#]] inherits from the Object class. [[Java (programming language)|Java]] has several primitive types that are not objects. Java provides wrapper object types that exist together with the primitive types so developers can use either the wrapper object types or the simpler non-object primitive types.
| |
| | |
| ==Compatibility: equivalence and subtyping==
| |
| A type-checker for a statically typed language must verify that the type of any [[expression (programming)|expression]] is consistent with the type expected by the context in which that expression appears. For instance, in an [[assignment statement]] of the form <code>x := ''e''</code>,
| |
| the inferred type of the expression ''<code>e</code>'' must be consistent with the declared or inferred type of the variable <code>x</code>. This notion of consistency, called ''compatibility'', is specific to each programming language.
| |
| | |
| If the type of ''<code>e</code>'' and the type of <code>x</code> are the same and assignment is allowed for that type, then this is a valid expression. In the simplest type systems, therefore, the question of whether two types are compatible reduces to that of whether they are ''equal'' (or ''equivalent''). Different languages, however, have different criteria for when two type expressions are understood to denote the same type. These different ''equational theories'' of types vary widely, two extreme cases being ''[[structural type system]]s'', in which any two types are equivalent that describe values with the same structure, and ''[[nominative type system]]s'', in which no two syntactically distinct type expressions denote the same type (''i.e.'', types must have the same "name" in order to be equal).
| |
| | |
| In languages with [[subtype|subtyping]], the compatibility relation is more complex. In particular, if <code>A</code> is a subtype of <code>B</code>, then a value of type <code>A</code> can be used in a context where one of type <code>B</code> is expected, even if the reverse is not true. Like equivalence, the subtype relation is defined differently for each programming language, with many variations possible. The presence of parametric or ad hoc [[polymorphism (computer science)|polymorphism]] in a language may also have implications for type compatibility.
| |
| | |
| ==Programming style==
| |
| Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program.<ref>{{cite web
| |
| |url=http://research.microsoft.com/en-us/um/people/emeijer/Papers/RDL04Meijer.pdf
| |
| |title=Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages
| |
| |last1=Meijer
| |
| |first1=Erik
| |
| |last2=Drayton
| |
| |first2=Peter
| |
| |publisher=[[Microsoft]] Corporation }}</ref><ref>{{cite web
| |
| |url=http://www.infoq.com/presentations/Types-Tests
| |
| |title=Types vs Tests
| |
| |last1=Laucher
| |
| |first1=Amanda
| |
| |last2=Snively
| |
| |first2=Paul
| |
| |publisher=InfoQ }}</ref> Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimizers <ref>{{cite web
| |
| |url=http://www.mozilla.com/en-US/press/mozilla-2006-11-07.html
| |
| |title=Adobe and Mozilla Foundation to Open Source Flash Player Scripting Engine }}</ref><ref>{{cite web
| |
| |url=http://psyco.sourceforge.net/introduction.html
| |
| |title=Psyco, a Python specializing compiler }}</ref> that can generate fast code approaching the speed of static language compilers, often by using partial type inference.<ref>[http://www.cython.org/ C-Extensions for Python]. Cython (2013-05-11). Retrieved on 2013-07-17.</ref>
| |
| | |
| ==See also==
| |
| * [[Comparison of type systems]]
| |
| * [[Covariance and contravariance (computer science)]]
| |
| * [[Operator overloading]]
| |
| * [[Polymorphism in object-oriented programming]]
| |
| * [[Programming language]]
| |
| * [[Signedness]]
| |
| * [[Type rules]]
| |
| * [[Type signature]]
| |
| * [[Type theory]]
| |
| | |
| ==References==
| |
| {{Reflist|2}}
| |
| | |
| ==Further reading==
| |
| * {{cite journal|last1 = Cardelli|first1=Luca|authorlink1=Luca Cardelli|last2=Wegner|first2=Peter|authorlink2=Peter Wegner|title = On Understanding Types, Data Abstraction, and Polymorphism|url=http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf|journal = [[ACM Computing Surveys]]|date = December 1985| volume = 17|issue=4|issn = 0360-0300|pages = 471–523|doi = 10.1145/6041.6042|publisher = [[Association for Computing Machinery|ACM]]|location = New York, NY, USA | ref = harv}}
| |
| * {{cite book|first=Benjamin C.|last=Pierce|authorlink=Benjamin C. Pierce|year=2002|title=Types and Programming Languages|publisher=MIT Press|isbn=978-0-262-16209-8 | ref = harv}}
| |
| * {{cite book|first=Luca|last=Cardelli|authorlink=Luca Cardelli|editor=Allen B. Tucker|title=CRC Handbook of Computer Science and Engineering|edition=2nd|chapter=Type systems|year=2004|publisher=CRC Press|url=http://lucacardelli.name/Papers/TypeSystems.pdf|isbn=158488360X|ref=harv}}
| |
| * Tratt, Laurence, [http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/ ''Dynamically Typed Languages''], Advances in Computers, Vol. 77, pp. 149–184, July 2009
| |
| | |
| ==External links==
| |
| {{wikibooks|Ada Programming|Types}}
| |
| {{wikibooks|Haskell|Class Declarations}}
| |
| * Smith, Chris, [http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ ''What To Know Before Debating Type Systems'']
| |
| | |
| {{Data types}}
| |
| | |
| {{DEFAULTSORT:Type System}}
| |
| [[Category:Type systems| ]]
| |
| [[Category:Data types]]
| |
| [[Category:Program analysis]]
| |
| [[Category:Type theory]]
| |
| | |
| [[de:Typisierung (Informatik)#Typsystem]]
| |