¿"untyped "también significa" dinámicamente mecanografiado " en el mundo académico de CS?

Soy un científico informático académico especializado en lenguajes de programación, y sí, la palabra "untyped" se usa con frecuencia (mal) de esta manera. Sería bueno reservar la palabra para su uso con lenguajes que no llevan etiquetas de tipo dinámico, como el código Forth y ensamblador, pero estos lenguajes rara vez se usan y aún más raramente se estudian, y es mucho más fácil decir "untyped" que "dinámicamente tipeado".

A Bob Harper le gusta decir que lenguajes como Scheme, Javascript, etc. deben considerarse lenguajes tipeados con un solo tipo: valor. Me inclino a este punto de vista, ya que hace posible construir una visión del mundo consistente utilizando solo un formalismo tipo.

P.d. En el cálculo lambda puro, los únicos "valores" son términos en forma normal, y los únicos términos cerrados en forma normal son funciones. Pero la mayoría de los científicos que usan el cálculo lambda agregan tipos base y constantes, y luego incluyen un sistema de tipos estáticos para lambda o vuelven a etiquetas de tipo dinámico.

P. P. S. To original poster: cuando se trata de lenguajes de programación, y especialmente sistemas de tipos, la información en Wikipedia es de mala calidad. No confíes en él.

He mirado en él, y encontré que la respuesta a su pregunta es simplemente, y sorprendentemente, "sí": los tipos CS académicos, o al menos algunos de ellos, usan "sin tipo" para significar "dinámicamente tipeado". Por ejemplo, Lenguajes de programación: Principios y Prácticas , Tercera Edición (por Kenneth C. Louden y Kenneth A. Lambert, publicado en 2012) dice esto:

Los lenguajes sin sistemas de tipos estáticos generalmente se llaman lenguajes sin tipo (o dinámicamente tipeados languages). Tales lenguajes incluyen Scheme y otros dialectos de Lisp, Smalltalk, y la mayoría de los lenguajes de scripting como Perl, Python y Ruby. Tenga en cuenta, sin embargo, que un lenguaje sin tipo no necesariamente permite que los programas corrompan datos, esto solo significa que todas las comprobaciones de seguridad se realizan en el momento de la ejecución. […]

[link] (nota: negrita en original) y continúa usando "untyped" de esta manera.

Encuentro esto sorprendente (por las mismas razones que afrischke y Adam Mihalcin dan), pero ahí estás. :-)

Edited to add: Puedes encontrar más ejemplos conectando "untyped languages" en la búsqueda de libros de Google. Por ejemplo:

[This] Este es el principal mecanismo de ocultación de información son muchos lenguajes sin tipo. Por ejemplo, el esquema PLT [4] utiliza generativos struct s, [{]

- Jacob Matthews y Amal Ahmed, 2008 [link ]

[...], presentamos un análisis de tiempo de unión para un funcional sin tipo idioma […]. []] Se ha implementado y se utiliza en un evaluador parcial para un dialecto libre de efectos secundarios de Scheme. Sin embargo, el análisis es lo suficientemente general como para ser válido para lenguajes funcionales tipeados no estrictos como Haskell. […]

- Charles Consel, 1990 [link ]

Por cierto, mi impresión, después de mirar a través de estos resultados de búsqueda, es que si un investigador escribe de un lenguaje funcional "sin tipo", es muy probable que lo considere" sin tipo " en el mismo sentido que el cálculo lambda no tipificado que menciona Adam Mihalcin. Al menos, varios investigadores mencionan Esquema y el cálculo lambda en la misma respiración.

Lo que la búsqueda no dice, por supuesto, es si hay investigadores que rechazan esta identificación, y no consideran que estos idiomas están "sin tipo". Bueno, encontré esto:

Entonces me di cuenta de que realmente no hay circularidad, porque los lenguajes tipeados dinámicamente no son idiomas sin escribir-es solo que los tipos no suelen ser inmediatamente obvios en el texto del programa.

- alguien (no puedo decir quién), 1998 [ link ]

Pero obviamente la mayoría de las personas que rechazan esta identificación no sentirían la necesidad de decirlo explícitamente.

Untyped y dinámicamente tiped no son sinónimos en absoluto. El lenguaje que más a menudo se llama" untyped " es el Cálculo Lambda, que en realidad es un lenguaje unityped - todo es una función, por lo que podemos demostrar estáticamente que el tipo de todo es la función. Un lenguaje dinámicamente escrito tiene varios tipos, pero no agrega una forma para que el compilador los verifique estáticamente, forzando al compilador a insertar comprobaciones de tiempo de ejecución en tipos de variables.

Entonces, JavaScript es un lenguaje dinámicamente escrito: es posible escribir programas en JavaScript de tal manera que alguna variable x podría ser un número, o una función, o una cadena, o algo más (y determinar cuál requeriría resolver el Problema de Detención o algún problema matemático difícil), por lo que puede aplicar x a un argumento y el navegador tiene que comprobar en tiempo de ejecución que x es una función.

Ambas sentencias son correctas, dependiendo de si se trata de valores o variables. Las variables de JavaScript no tienen tipo, los valores de JavaScript tienen tipos y las variables pueden variar sobre cualquier tipo de valor en tiempo de ejecución (es decir, 'dinámicamente').

En JavaScript y muchos otros lenguajes, los valores y no las variables llevan tipos. Todas las variables pueden variar sobre todos los tipos de valores y pueden considerarse "dinámicamente tipadas" o "sin tipar", desde la perspectiva de la comprobación de tipo de una variable que tiene el tipo no / unknowable y una variable que puede tomar cualquier tipo son lógica y prácticamente equivalentes. Cuando los teóricos de tipos hablan de lenguajes y tipos, generalmente están hablando de esto-variables que llevan tipos-porque están interesados en escribir comprobadores de tipos y compiladores, etc., que operan en el texto del programa (es decir, variables) y no en un programa en ejecución en memoria (es decir, valores).

Por el contrario, en otros lenguajes, como C, las variables llevan tipos pero los valores no. En idiomas al igual que Java, las variables y los valores tienen tipos. En C++, algunos valores (aquellos con funciones virtuales) llevan tipos y otros no. En algunos idiomas incluso es posible que los valores cambien de tipo, aunque esto generalmente se considera un mal diseño.

Esta pregunta es todo sobre Semántica

Si te doy estos datos: 12 ¿cuál es su tipo? No tienes forma de saberlo con seguridad. Podría ser un entero-podría ser un flotador-podría ser una cadena. En ese sentido, son datos muy "sin tipo".

Si le doy un lenguaje imaginario que le permite usar operadores como "agregar", "restar" y "concatenar" en estos datos y algún otro dato arbitrario, el "tipo" es algo irrelevante (para mi lenguaje imaginario) (ejemplo: quizás add(12, a) produce 109 que es 12 más el valor ascii de a).

Hablemos de C por un segundo. C te permite hacer lo que quieras con cualquier dato arbitrario. Si estás usando una función que toma dos uint s - podrías lanzar y pasar lo que quieras - y los valores simplemente se interpretarán como uint s. En ese sentido C es "sin tipo" (si lo tratas de esa manera).

Sin embargo-y llegando al punto de Brendan - si te dijera que " Mi edad es 12" - entonces 12 tiene un tipo - al menos sabemos que es numérico. Con contexto todo tiene un tipo - independientemente del lenguaje.

Esta es la razón por la que dije al principio - su pregunta es una de semántica. ¿Cuál es el significado de"untyped"? Creo que Brendan dio en el clavo cuando dijo "sin tipos estáticos", porque eso es todo lo que puede significar. Los humanos naturalmente clasifican las cosas en tipos. Intuitivamente sabemos que hay algo fundamentalmente diferente entre un un coche y un mono, sin que se les enseñara a hacer esas distinciones.

Volviendo a mi ejemplo al principio: un lenguaje que "no se preocupa por los tipos" (per - se) puede permitirle "agregar" una "edad" y un "nombre" sin producir un error de sintaxis... pero eso no significa que sea una operación lógica.

Javascript puede permitirle hacer todo tipo de cosas locas sin considerarlas "errores". Eso no significa que lo que estás haciendo sea lógico. Eso es para el desarrollador para hacer ejercicio.

¿Es un sistema/lenguaje que no impone la seguridad de tipos en el tiempo de compilación/compilación/interpretación "untyped "o"dinámicamente typed"?

Semántica.

EDITAR

Quería agregar algo aquí porque algunas personas parecen estar atrapadas en "sí, pero Javascript tiene algunos "tipos"".

En mi comentario sobre la respuesta de otra persona dije: {[13]]}

En Javascript podría tener objetos que he construido para ser "Monos" y objetos que he construido para ser " Humanos "y algunas funciones podrían estar diseñadas para operar solo en" Humanos", otras solo en" Monos", y otras solo en"Cosas con Brazos". Si alguna vez se le ha dicho al lenguaje que existe una categoría de objetos como "cosas con brazos"es tan irrelevante para assembly ("untyped") como lo es para Javascript ("dynamic"). Todo es una cuestión de integridad lógica, y el único error sería usar algo que no tiene armas con ese método.

Por lo tanto, si considera que Javascript tiene alguna "noción de tipos" internamente - y, por lo tanto, "tipos dinámicos" - y piensa que esto es de alguna manera "claramente diferente de un sistema sin tipo" - debería ver en el ejemplo anterior que cualquier "noción de tipos" que tenga internamente es realmente irrelevante.

Para realizar la misma operación con C#, por ejemplo, necesitaría una interfaz llamada ICreatureWithArms o algo similar. No es así en Javascript-no es así en C o ASM.

Claramente, si Javascript tiene o no alguna comprensión de los "tipos" es irrelevante.

No soy un científico de la computación, pero me sorprendería si "untyped" fuera realmente usado como sinónimo de "dinámicamente tipado" en la comunidad CS (al menos en publicaciones científicas) ya que en mi humilde opinión esos dos términos describen conceptos diferentes. Un lenguaje dinámicamente escrito tiene una noción de tipos y aplica las restricciones de tipo en tiempo de ejecución (por ejemplo, no puede dividir un entero por una cadena en Lisp sin obtener un error), mientras que un lenguaje sin tipo no tiene ninguna noción de tipos en todos (por ejemplo, ensamblador). Incluso el artículo de Wikipedia sobre lenguajes de programación (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) hace esta distinción.

Actualización: Tal vez la confusión proviene del hecho de que algunos textos dicen algo en la medida en que "las variables no se escriben" en Javascript (lo cual es cierto). Pero eso no significa automáticamente que el idioma no está escrito (lo que sería falso).

De acuerdo con Brendan - el contexto lo es todo.

Mi opinión:

Recuerdo haber estado confundido, alrededor de 2004, porque había argumentos que surgían sobre si Ruby estaba sin escribir o dinámicamente escrito. La gente de C/C++ de la vieja escuela (de la que yo era una) estaba pensando en el compilador y diciendo que Ruby no tenía tipo.

Recuerde, en C, no hay tipos de tiempo de ejecución, solo hay direcciones y si el código que se está ejecutando decide tratar lo que está en esa dirección como algo que no lo es, ups. Eso es definitivamente untyped y muy diferente de dinámicamente mecanografiado.

En ese mundo, "typing" tiene que ver con el compilador. C++ tenía "escritura fuerte" porque las comprobaciones del compilador eran más estrictas. Java y C estaban más "débilmente tipeados" (incluso había argumentos sobre si Java estaba fuertemente o débilmente tipeado). Los lenguajes dinámicos estaban, en ese continuo," sin tipo " porque no tenían verificación de tipo de compilador.

Hoy, para los programadores practicantes, estamos tan acostumbrados a lenguajes dinámicos, obviamente pensamos que untyped significa que no hay compilador ni intérprete de verificación de tipos, lo que sería increíblemente difícil de depurar. Pero hubo un período allí donde eso no era obvio y en el mundo más teórico de CS is puede ni siquiera ser significativo.

En un sentido profundo, nada puede ser sin escribir (o casi nada, de todos modos) porque debe tener alguna intención de manipular un valor para escribir un algoritmo significativo. Este es el mundo de la CS teórica, que no está tratando con los detalles de cómo se implementa un compilador o intérprete para un lenguaje dado. Así que "sin tipo" es (probablemente, no lo sé) completamente sin sentido en ese contexto.

Si bien es cierto que la mayoría de los investigadores de CS que escriben sobre tipos esencialmente consideran solo lenguajes con tipos sintácticamente derivables como lenguajes tipeados, hay muchos más de nosotros que usan lenguajes tipeados dinámicamente/latentemente que se ofenden por ese uso.

Considero que hay 3 tipos [SIC] de idiomas:

Untyped - solo el operador determina la interpretación del valor - y generalmente funciona en cualquier cosa. Ejemplos: Ensamblador, BCPL

Las expresiones/variables de tipo estático tienen tipos asociados a ellas, y ese tipo determina la interpretación/validez del operador en tiempo de compilación. Ejemplos: C, Java, C++, ML, Haskell

Dinámicamente typed - los valores tienen tipos asociados con ellos, y ese tipo determina la interpretación/validez del operador en tiempo de ejecución. Ejemplos: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

Que yo sepa, todos los lenguajes dinámicamente tipeados son type-safe-es decir, solo los operadores válidos pueden operar con valores. Pero lo mismo no es cierto para el lenguaje estáticamente mecanografiado. Dependiendo de la potencia del tipo de sistema utilizado, algunos operadores pueden ser comprobados solo en tiempo de ejecución, o no en absoluto. Por ejemplo, la mayoría de los lenguajes de tipo estático no manejan el desbordamiento de enteros correctamente (agregar 2 enteros positivos puede producir un entero negativo), y las referencias de matrices fuera de límite no se comprueban en absoluto (C, C++) o solo se comprueban en tiempo de ejecución. Además, algunos los sistemas de tipos son tan débiles que la programación útil requiere escotillas de escape (casts en C y family) para cambiar el tipo de expresiones en tiempo de compilación.

Todo esto conduce a afirmaciones absurdas, como que C++ es más seguro que Python porque es (estáticamente tipeado), mientras que la verdad es que Python es intrínsecamente seguro mientras que puedes dispararte con C++.