Sistema de tipificacion

Sistema de tipificación
Sistema de tipificación
En ciencias de la computación, un sistema de tipificación define cómo un lenguaje de programación clasifica los
valores y las expresiones en tipos, cómo se pueden manipular estos tipos y cómo interactúan. Un tipo indica un
conjunto de valores que tienen el mismo significado genérico o propósito (aunque algunos tipos, como los tipos de
datos abstractos y tipos de datos función, tal vez no representen valores en el programa que se está ejecutando). Los
sistemas de tipificación varían significativamente entre lenguajes, siendo quizás las más importantes variaciones las
que estén en sus implementaciones de la sintáctica en tiempo de compilación y la operativa en tiempo de ejecución.
Un compilador puede usar el tipo estático de un valor para optimizar el almacenamiento que necesita y la elección de
los algoritmos para las operaciones sobre ese valor. Por ejemplo, en muchos compiladores de C el tipo de dato
"flotante" se representa en 32 bits, de acuerdo con la especificación IEEE para los números de coma flotante de
simple precisión. Entonces, C usa operaciones específicas de coma flotante sobre estos valores (suma de coma
flotante, multiplicación, etc.).
El rango del tipo de dato limita y la forma de su evaluación afecta en el "tipificado" del lenguaje. Además, un
lenguaje de programación puede asociar una operación concreta con diferentes algoritmos para cada tipo de dato en
el caso del polimorfismo. La teoría de tipos de datos es el estudio de los sistemas de tipificación, aunque los sistemas
de tipos de datos concretos de los lenguajes de programación se originaron a partir de los problemas técnicos de las
arquitecturas del ordenador, implementación del compilador y diseño del lenguaje.
Básicos
Asignar tipos de datos (tipificar) da significado a colecciones de bits. Los tipos de datos normalmente tienen
asociaciones tanto con valores en la memoria o con objetos como con variables. Como cualquier valor simplemente
consiste en un conjunto de bits de un ordenador, el hardware no hace distinción entre dirección de memoria, código
de instrucción, caracteres, enteros y números en coma flotante. Los tipos de datos informan a los programas y
programadores cómo deben ser tratados esos bits.
Las principales funciones que los sistemas de tipificación ofrecen son:
• Seguridad - El uso de tipos de datos puede permitir a un compilador detectar incoherencias en el significado o
código probablemente inválido. Por ejemplo, podemos identificar una expresión 3 / "Hello, World" como inválida
porque no se puede dividir (de forma normal) un entero por una cadena de caracteres. Un sistema de tipificado
fuerte ofrece más seguridad, pero no garantiza, necesariamente una seguridad completa (ver seguridad de la
tipificación para más información).
• Optimización - Un sistema de tipificado estático puede dar información muy útil al compilador. Por ejemplo, si
un tipo de dato dice que un valor debe alinearse en múltiplos de 4, el compilador puede usar de forma más
eficiente las instrucciones máquina.
• Documentación - En sistemas de tipificación más expresivos, los tipos de datos pueden servir como una forma de
documentación, porque pueden ilustrar la intención del programador. Por ejemplo, los ítem de tiempos pueden ser
un subtipo de un entero, pero si un programador declara una función como que devuelve ítems de tiempo en lugar
de un simple entero, esto documenta parte del significado de la función.
• Abstracción (o modularidad) - Los tipos de datos permiten a los programadores pensar en los programas a un
alto nivel, sin tener que preocuparse con el bajo nivel de la implementación. Por ejemplo, los programadores
pueden pensar en una cadena de caracteres como un valor en lugar de un simple array de bytes. O los tipos de
datos pueden permitir a los programadores expresar la Interfaz entre dos subsistemas. Esto localiza las
definiciones requeridas para la interoperabilidad de los subsistemas y previene de inconsistencias cuando estos
subsistemas se comuniquen.
1
Sistema de tipificación
Un programa normalmente asocia cada valor con un tipo de dato determinado (aunque un tipo de dato puede tener
más de un subtipo). Otras entidades, como los objetos, bibliotecas, canales de comunicación, dependencias o,
incluso, los propios tipos de datos, pueden ser asociados con un tipo de dato. Por ejemplo:
• Tipo de dato - un tipo de dato de un valor
• clase - un tipo de dato de un objeto
Un sistema de tipificado, especificado en cada lenguaje de programación, estipula las formas en que los programas
pueden ser escritos y hace ilegal cualquier comportamiento fuera de estas reglas.
Chequeo de tipificación
El proceso de verificar e imponer los límites impuestos por los tipos de datos –chequeo de tipificación– puede
ocurrir tanto en tiempo de compilación (un chequeo estático) o en tiempo de ejecución (un chequeo dinámico). Si un
lenguaje impone fuertemente las reglas de tipificación (es decir, generalmente permitiendo solo las conversiones de
tipo de dato automáticas que no hagan perder información), uno se puede referir al proceso como fuertemente
tipificado; sino, débilmente tipificado.
Tipificado estático
Se dice de un lenguaje de programación que usa un tipificado estático cuando el chequeo de tipificación se realiza
durante el tiempo de compilación, opuesto al de ejecución. Ejemplos de lenguajes que usan tipificado estático son C,
C++, Java y Haskell. Comparado con el tipificado dinámico, el estático permite que los errores de programación
sean detectados antes, y que la ejecución del programa sea más eficiente.
Tipificado dinámico
Se dice de un lenguaje de programación que usa un tipificado dinámico cuando el chequeo de tipificación se realiza
durante el tiempo de ejecución, opuesto al de compilación. Ejemplos de lenguajes que usan tipificado dinámico son
Perl, Python y Lisp. Comparado con el tipificado estático, o sistema de enlazado temprano, el tipificado dinámico es
más flexible (debido a las limitaciones teóricas de la decidibilidad de ciertos problemas de análisis de programas
estáticos, que impiden el mismo nivel de flexibilidad que se consigue con el tipificado estático), a pesar de ejecutarse
más lentamente y más propensos a contener errores de programación.
Tipificado estático y dinámico combinados
Algunos lenguajes estáticamente tipificados tienen una "puerta trasera" en el lenguaje que permite a los
programadores escribir código que no es chequeado estáticamente. Por ejemplo, los lenguajes como Java y los
parecidos al C tienen una "conversión de tipos de datos forzada (cast)"; estas operaciones pueden ser inseguras en
tiempo de ejecución, por que pueden causar comportamientos indeseados cuando el programa se ejecuta.
La presencia de un tipificado estático en un lenguaje de programación no implica necesariamente la ausencia de
mecanismos de tipificado dinámico. Por ejemplo, Java usa tipificado estático, pero ciertas operaciones requieren el
soporte de test de tipos de datos en tiempo de ejecución, que es una forma de tipificado dinámico. Ver lenguaje de
programación para una discusión más amplia de la interacción entre tipificado estático y dinámico.
2
Sistema de tipificación
Chequeo de tipificación estático y dinámico en la práctica
La elección entre sistemas de tipificación dinámico y estático requiere algunas contra prestaciones.
El tipificado estático busca errores en los tipos de datos en tiempo de compilación. Esto debería incrementar la
fiabilidad de los programas procesados. Sin embargo, los programadores, normalmente, están en desacuerdo en
cómo los errores de tipos de datos más comunes ocurren, y en qué proporción de estos errores que se han escrito
podrían haberse cazado con un tipificado estático. El tipificado estático aboga por la creencia de que los programas
son más fiables cuando son chequeados sus tipos de datos, mientras que el tipificado dinámico apunta al código
distribuido que se ha probado que es fiable y un conjunto pequeño de errores. El valor del tipificado estático,
entonces, es que se incrementa a la par que se endurece el sistema de tipificación. Los defensores de los lenguajes
fuertemente tipificados como ML y Haskell han sugerido que casi todos los errores pueden ser considerados errores
de los tipos de datos, si los tipos de datos usados en un programa están suficientemente bien declarados por el
programador o inferidos por el compilador.[1]
El tipificado estático resulta, normalmente, en un código compilado que se ejecuta más rápidamente. Cuando el
compilador conoce los tipos de datos exactos que están en uso, puede producir código máquina optimizado. Además,
los compiladores en los lenguajes de tipificado estático pueden encontrar atajos más fácilmente. Algunos lenguajes
de tipificación dinámica como el lisp permiten declaraciones de tipos de datos opcionales para la optimización por
esta misma razón. El tipificado estático generaliza este uso. Ver optimización de software
En contraste, el tipificado dinámico permite a los compiladores e intérpretes ejecutarse más rápidamente, debido a
que los cambios en el código fuente en los lenguajes dinámicamente tipificados puede resultar en un menor chequeo
y menos código que revisar. Esto también reduce el ciclo editar-compilar-comprobar-depurar.
Lenguajes estáticamente tipificados que no dispongan de inferencia (como Java), requieren que el programador
declare los tipos de datos que un método o función puede procesar. Esto puede hacer la veces de documentación
adicional del programa, que el compilador no permitirá que el programador ignore o drift out of synchronization. Sin
embargo, un lenguaje puede ser de tipificación estática sin requerir la declaración del tipo de dato (ejemplos incluyen
Scala y C#3.0), así que esto no es una consecuencia de tipificación estática.
El tipado dinámico permite construcciones que algunos sistemas de tipado estatico rechazarían al considerarlas
ilegales. Por ejemplo, la función eval de Python, la cual ejecuta datos arbitrarios como si fueran código. Además, el
tipado dinámico es más adecuado para código de transición o para el prototipado. Desarrollos recientes en lenguajes
como Haskell (por ejemplo, los tipos algebraicos generalizados), permiten a lenguajes de tipado estatico, ejecutar
código a partir de estructuras de datos de una forma segura.
El tipificado dinámico típicamente hace que la metaprogramación sea más poderosa y fácil de usar. Por ejemplo,
C++ templates son típicamente más engorrosas de escribir que su equivalente en Ruby o Python.[cita requerida] More
advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically-typed
languages.
Referencias
[1] Dependent Types in Practical Programming - Xi, Pfenning (ResearchIndex) (http:/ / citeseer. ist. psu. edu/ xi98dependent. html)
Esta página o sección está siendo traducida del idioma inglés a partir del artículo Type system, razón por la cual puede haber
lagunas de contenidos, errores sintácticos o escritos sin traducir.
Puedes colaborar con Wikipedia de tipificación continuando con la traducción (http:/ / en. wikipedia. org/ wiki/ :Sistema)
desde el artículo original.
3
Sistema de tipificación
Strong and weak typing
-- This section is linked from Java (programming language) -One definition of strongly typed involves not allowing an operation to succeed on arguments which have the wrong
type. A C cast gone wrong exemplifies the absence of strong typing; if a programmer casts a value in C, not only
must the compiler allow the code, but the runtime should allow it as well. This allows compact and fast C code, but it
can make debugging more difficult.
Some pundits use the term memory-safe language (or just safe language) to describe languages that do not allow
undefined operations to occur. For example, a memory-safe language will also check array bounds.
Weak typing means that a language implicitly converts (or casts) types when used. Revisiting the previous example:
var x := 5; // (1)
var y := "37"; // (2)
x + y; // (3)
Writing the code above in a weakly-typed language, it is not clear what kind of result one would get. Some
languages, such as Visual Basic, would produce runnable code which would yield the result 42: the system would
convert the string "37" into the number 37 to make sense of the operation; other languages like JavaScript would
produce the result "537": the system would convert the number 5 to the string "5" and then concatenate the two. In
both Visual Basic and JavaScript, the resulting type is determined by rules that take both operands into
consideration. In some languages, such as AppleScript, the resulting type of a value is determined by the type of the
left-most operand only.
Careful language design has also allowed languages to appear weakly-typed (through type inference and other
techniques) for usability while preserving the type checking and protection offered by strongly-typed languages.
Examples include VB.Net, C# and Java.
Reduction of operator overloading, such as not using "+" for string concatenation in addition to arithmetic addition,
can reduce some of the confusion caused by weak typing.[cita requerida] For example, PHP uses periods (.) for string
concatenation, and similarly Ada uses ampersands (&).
===Safely and unsafely typed systems=== -- This section is linked from Java (programming language) -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
which lead to erroneous conditions.
Let us again have a look at the pseudocode example:
var x := 5; // (1)
var y := "37"; // (2)
var z := x + y; // (3)
In languages like Visual Basic variable z in the example acquires the value 42. While the programmer may or may
not have intended this, the language defines the result specifically, and the program does not crash or assign an
ill-defined value to z. In this respect, such languages are type-safe.
Now let us look at the same example in C:
int x = 5;
char y[] = "37";
char* z = x + y;
In this example z will point to a memory address five characters beyond y, equivalent to two characters after the
terminating zero character of the string pointed to by y. The content of that location is undefined, and might lie
4
Sistema de tipificación
outside addressable memory. The mere computation of such a pointer may result in undefined behavior (including
the program crashing) according to C standards, and in typical systems dereferencing z at this point could cause the
program to crash. We have a well-typed, but not memory-safe program — a condition that cannot occur in a
type-safe language.
Polymorphism and types
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, modularity and (in some cases) subtyping.
Duck typing
En "duck typing," la llamada a un método de un objeto no depende del tipo de objeto; simplemente basta con que el
objeto -cualquiera sea su tipo- implemente el método invocado.
El término duck typing fue acuñado inicialmente por Alex Martelli en la comunidad Python, y usa la premisa
(refiriéndose al valor) de que "si algo camina como un pato y se oye como un pato, entonces debe ser un pato".
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 types are based on the idea of using scalars or values to more precisely describe the type of some other
value. For example, "matrix(3,3)" might be the type of a 3×3 matrix. We can then define typing rules such as the
following rule for matrix multiplication:
matrix_multiply : matrix(k,m) × matrix(m,n) → matrix(k,n)
where k, m, n are arbitrary positive integer values. A variant of ML called Dependent ML has been created based on
this type system, but because type-checking conventional dependent types is undecidable, not all programs using
them can be type-checked without some kind of limitations. Dependent ML limits the sort of equality it can decide to
Presburger arithmetic; other languages such as Epigram make the value of all expressions in the language decidable
so that type checking can be decidable.
Linear types
Linear types, based on the theory of linear logic, and also known as uniqueness types, 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 values such as strings, files, and so on, because any operation that simultaneously destroys a linear
object and creates a similar object (such as 'str = str + "a"') can be optimized "under the hood" into an in-place
mutation. Normally this is not possible because such mutations could cause side effects on parts of the program
holding other references to the object, violating referential transparency. They're also used in the prototype operating
system Singularity for interprocess communication, statically ensuring that processes cannot share objects in shared
memory in order to prevent race conditions. The Clean language (a Haskell-like language) uses this type system in
5
Sistema de tipificación
order to gain a lot of speed while remaining safe.
Intersection types
Intersection types are types describing values that belong to both of two other given types with overlapping value
sets. For example, in 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 "int → int" is the type of
functions taking an integer argument and returning an integer, and "float → 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're given. Such a function could be passed into another function
expecting an "int → int" function safely; it simply wouldn't use the "float → 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
types.
Union types
Union types 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 because 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 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 types are frequently used to represent modules and abstract data types because of their ability to separate
implementation from interface. For example, in C pseudocode, the type "T = ∃X { X a; int f(X); }" describes a
module interface that has a data member of type X and a function that takes a parameter of the same type X and
returns an integer. This could be implemented in different ways; for example:
• intT { int a; int f(int); }
• floatT { float a; int f(float); }
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.
6
Sistema de tipificación
Explicit or implicit declaration and inference
Many static type systems, such as C's and Java's, 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 f(x,y) which adds x and y together, the compiler can infer that x and y must be numbers – since addition is
only defined for numbers. Therefore, any call to 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 3.14 might imply a type of floating-point, while [1, 2, 3] might imply a list of integers –
typically an array.
Types of types
A type of types is a kind. Kinds appear explicitly in typeful programming, such as a type constructor in the Haskell
programming language, which returns a simple type after being applied to enough simple types. For example, the
type constructor Either has the kind * -> * -> * and its application Either String Integer is a simple type (kind *).
However, in most programming languages type construction is implicit and hard coded in the grammar; there is no
notion of kind as a first class entity.
Types fall into several broad categories:
• primitive types — the simplest kind of type; e.g., integer and floating-point number
• boolean
• integral types — types of whole numbers; e.g., integers and natural numbers
• floating point types — types of numbers in floating-point representation
• reference types
• null types
• composite types — types composed of basic types; e.g., arrays or records. Abstract data types have attributes of
both composite types and interfaces, depending on context.
• subtype
• derived type
• object types; e.g., type variable
• partial type
• recursive type
• function types; e.g., binary functions
• universally quantified types, such as parameterized types
• existentially quantified types, such as modules
• refinement types — types which identify subsets of other types
• dependent types — types which depend on run-time values
• ownership types — types which describe or constrain the structure of object-oriented systems
7
Sistema de tipificación
Compatibility: equivalence and subtyping
A type-checker for a statically typed language must verify that the type of any expression is consistent with the type
expected by the context in which that expression appears. For instance, in an assignment statement of the form x :=
e, the inferred type of the expression e must be consistent with the declared or inferred type of the variable x. This
notion of consistency, called compatibility, is specific to each programming language.
If the type of e and the type of x 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 systems, in which any two types are equivalent that describe values with the same structure, and
nominative type systems, 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 subtyping, the compatibility relation is more complex. In particular, if A is a subtype of B, then a
value of type A can be used in a context where one of type B 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 in a language may also have implications for type
compatibility.
Controversia
Hay frecuentemente conflictos entre aquellos que prefieren la tipificación fuerte y/o estátitica y aquellos que se
inclinan por la tipificación dinámica o libre. El primer grupo avoga por la detección temprana de errores durante la
compilación y el aumento de rendimiento en tiempo de ejecución, mientras que el segundo grupo avoga por los
prototipos rápidos que son posibles con un sistema de tipificación dinámico.[1] Related to this is the consideration
that often there is no need to manually declare types in a programming language with type inference; thus, the
overhead is automatically lowered for some languages.
Referencias
[1] Meijer, Erik and Peter Drayton. « Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between
Programming Languages (http:/ / pico. vub. ac. be/ ~wdmeuter/ RDL04/ papers/ Meijer. pdf)». Microsoft Corporation.
Véase también
Wikilibros
•
Wikilibros alberga un libro o manual sobre Types.
Wikilibros
•
•
•
•
•
•
•
Wikilibros alberga un libro o manual sobre Class Declarations.
Operator overloading
Polymorphism in object-oriented programming
Programming language
Type signature
Signedness
Type system cross reference list
8
Sistema de tipificación
Enlaces externos
• What To Know Before Debating Type Systems (http://cdsmith.twu.net/types.html), by Chris Smith
-->
9
Fuentes y contribuyentes del artículo
Fuentes y contribuyentes del artículo
Sistema de tipificación Fuente: http://es.wikipedia.org/w/index.php?oldid=42781822 Contribuyentes: Elwikipedista, GermanX, JoaquinFerrero, Jorge c2010, Larocka, Yeeliberto, 4 ediciones
anónimas
Fuentes de imagen, Licencias y contribuyentes
Archivo:Icono de traducción.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Icono_de_traducción.svg Licencia: GNU Free Documentation License Contribuyentes:
User:Rastrojo
Archivo:ISO 639 Icon en.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:ISO_639_Icon_en.svg Licencia: GNU Free Documentation License Contribuyentes: User:3247,
User:Nataraja
Image:Wikibooks-logo.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Wikibooks-logo.svg Licencia: logo Contribuyentes: User:Bastique, User:Ramac
Licencia
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/
10