¿"Sin tipo" también significa "tipo dinámico" en el mundo académico de CS?

Estoy leyendo un mazo de diapositivas que dice "JavaScript no tiene tipo". Esto contradecía lo que pensaba que era verdad, así que comencé a cavar para intentar aprender más.

Cada respuesta a ¿Es JavaScript un lenguaje sin tipo? dice que JavaScript no está sin tipo y ofrece ejemplos de varias formas de escritura estática, dinámica, fuerte y débil con las que estoy familiarizado y contento ... así que ese no era el camino a seguir.

Entonces le pregunté a Brendan Eich, el creador de JavaScript, y él dijo:

los tipos académicos usan "sin tipo" para significar "sin tipos estáticos". son lo suficientemente inteligentes como para ver que los valores tienen tipos (¡duh!). el contexto importa.

¿La gente de informática enfocada académicamente usa "sin tipo" como sinónimo de "tipo dinámico" (y es esto válido?) O hay algo más profundo en esto que me estoy perdiendo? Estoy de acuerdo con Brendan en que el contexto es importante, pero cualquier cita de explicaciones sería excelente, ya que mis libros actuales de "ir a" no están jugando mal en este tema.

Quiero concretar esto para poder mejorar mi comprensión y porque incluso Wikipedia no se refiere a este uso alternativo (que puedo encontrar, de todos modos). No quiero equivocarme con usar el término o cuestionar el uso del término en el futuro si me equivoco :-)

(¡También he visto que un Smalltalker superior dice que Smalltalk también está "sin tipo", por lo que no es una excepción, que es lo que me hizo saltar en esta búsqueda! :-))

Sí, esta es una práctica estándar en la literatura académica. Para entenderlo, es útil saber que la noción de "tipo" se inventó en la década de 1930, en el contexto del cálculo lambda (de hecho, incluso antes, en el contexto de la teoría de conjuntos). Desde entonces, ha surgido toda una rama de la lógica computacional que se conoce como "teoría de tipos". La teoría del lenguaje de programación se basa en estos fundamentos. Y en todos estos contextos matemáticos, "tipo" tiene un significado particular bien establecido.

La terminología "mecanografía dinámica" se inventó mucho más tarde, y es una contradicción de términos frente al uso matemático común de la palabra "tipo".

Por ejemplo, aquí está la definición de "sistema de tipos" que Benjamin Pierce usa en su libro de texto estándar Tipos y lenguajes de programación :

Un sistema de tipos es un método sintáctico manejable para demostrar la ausencia de ciertos comportamientos del programa clasificando frases de acuerdo con los tipos de valores que calculan.

Él también comenta:

La palabra "estática" a veces se agrega explícitamente (por ejemplo, hablamos de un "lenguaje de programación estáticamente tipado") para distinguir los tipos de análisis en tiempo de compilación que estamos considerando aquí del tipeo dinámico o latente que se encuentra en lenguajes como Scheme (Sussman y Steele, 1975; Kelsey, Clinger y Rees, 1998; Dybvig, 1996), donde las etiquetas de tipo de tiempo de ejecución se utilizan para distinguir diferentes tipos de estructuras en el montón. Términos como "tipeado dinámicamente" son posiblemente nombres incorrectos y probablemente deberían reemplazarse por "marcado dinámicamente", pero el uso es estándar.

La mayoría de las personas que trabajan en el campo parecen compartir este punto de vista.

Tenga en cuenta que esto no significa que "sin tipo" y "tipo dinámico" sean sinónimos. Más bien, que este último es un nombre (técnicamente engañoso) para un caso particular del primero.

PD: Y FWIW, resulta que soy tanto un investigador académico en sistemas de tipos como un implementador no académico de JavaScript, así que tengo que vivir con el schisma. :)

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

Bob Harper es aficionado a decir que los lenguajes como Scheme, Javascript, etc. deben considerarse lenguajes mecanografiados con un solo tipo: valor. Me inclino por esta vista, ya que hace posible construir una visión del mundo coherente utilizando solo un formalismo de tipo.

PD: 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 básicos y constantes, y luego se incluye un sistema de tipos estático para lambda o se regresa a las etiquetas de tipo dinámico.

PPS Al póster original: cuando se trata de lenguajes de programación, y especialmente sistemas de tipos, la información en Wikipedia es de baja calidad. No confíes en eso.

Lo investigué y descubrí que la respuesta a su pregunta es simple y sorprendentemente "sí": los tipos de CS académicos, o al menos algunos de ellos, usan "sin tipo" para significar "tipo dinámico". 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 idiomas sin sistemas de tipo estático generalmente se denominan idiomas sin tipo (o idiomas con tipo dinámico ). Dichos lenguajes incluyen Scheme y otros dialectos de Lisp, Smalltalk y la mayoría de los lenguajes de scripting como Perl, Python y Ruby. Sin embargo, tenga en cuenta que un lenguaje sin tipo no necesariamente permite que los programas corrompan los datos; esto solo significa que todas las comprobaciones de seguridad se realizan en el momento de la ejecución. [...]

[ enlace ] (nota: negrita en original) y continúa usando "sin tipo" de esta manera.

Esto me parece sorprendente (por las mismas razones que dan Afrischke y Adam Mihalcin), pero ahí estás. :-)

Editado para agregar: puede encontrar más ejemplos conectándose "untyped languages"a la Búsqueda de libros de Google. Por ejemplo:

[…] Este es el principal mecanismo de ocultación de información en muchos idiomas sin tipo. Por ejemplo, el esquema PLT [4] utiliza structs generativo , […]

- Jacob Matthews y Amal Ahmed, 2008 [ enlace ]

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

- Charles Consel, 1990 [ enlace ]

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

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

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

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

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

Sin tipo y con tipo dinámico no son sinónimos. El lenguaje que con mayor frecuencia se llama "sin tipo" es el cálculo Lambda, que en realidad es un lenguaje unificado: todo es una función, por lo que podemos demostrar estáticamente que el tipo de todo es la función. Un lenguaje de tipo dinámico tiene múltiples tipos, pero no agrega una forma para que el compilador los compruebe estáticamente, lo que obliga al compilador a insertar comprobaciones de tiempo de ejecución en tipos variables.

Entonces, JavaScript es un lenguaje de tipo dinámico: es posible escribir programas en JavaScript de manera que alguna variable xpueda ser un número, una función, una cadena u otra cosa (y determinar cuál requeriría resolver el problema de detención o alguna problema matemático difícil), por lo que puede aplicar xa un argumento y el navegador debe verificar en tiempo de ejecución que xsea ​​una función.

Ambas declaraciones son correctas, dependiendo de si se trata de valores o variables. Las variables de JavaScript no están tipificadas, 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 abarcar todos los tipos de valores y pueden considerarse "con tipo dinámico" o "sin tipo", desde la perspectiva de la verificación de tipo, una variable que no tiene tipo / no se puede conocer y una variable que puede tomar cualquier tipo es lógica y prácticamente equivalente. . Cuando los teóricos de tipos hablan de idiomas y tipos, generalmente hablan de esto, variables que llevan tipos, porque están interesados ​​en escribir verificadores de tipo y compiladores, etc., que operan en el texto del programa (es decir, variables) y no en un programa en ejecución en la memoria (es decir, valores).

Por el contrario, en otros lenguajes, como C, las variables llevan tipos pero los valores no. En lenguajes como Java, las variables y los valores llevan 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 sobre semántica

Si te doy estos datos: 12¿cuál es su tipo? No tienes forma de saberlo con certeza. 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 "sumar", "restar" y "concatenar" en estos datos y alguna otra pieza arbitraria de datos, el "tipo" es algo irrelevante (para mi lenguaje imaginario) (ejemplo : quizás add(12, a)rinde 109cuál es 12más el valor ascii de a).

Hablemos C por un segundo. C prácticamente te permite hacer lo que quieras con cualquier dato arbitrario. Si está utilizando una función que requiere dos uints, puede emitir y pasar lo que desee, y los valores simplemente se interpretarán como uints. En ese sentido, C no está "tipificado" (si lo trata de esa manera).

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

Es por eso que dije al principio: su pregunta es semántica. ¿Cuál es el significado de "sin tipo"? Creo que Brendan dio en el clavo cuando dijo "no hay 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 auto y un mono, sin que se nos enseñe 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ógicamente sólida.

Javascript puede permitirte hacer todo tipo de locuras sin considerarlas "errores". Eso no significa que lo que estás haciendo sea lógicamente correcto. Eso es para que el desarrollador lo resuelva.

¿Es un sistema / lenguaje que no exige la seguridad de tipos en tiempo de compilación / construcción / interpretación "sin tipo" o "con tipo dinámico"?

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:

En Javascript podría tener objetos que he creado para ser "Monos" y objetos que he creado para ser "Humanos" y algunas funciones podrían diseñarse para operar solo en "Humanos", otras solo en "Monos", y y otros solo en "Cosas con armas". Si alguna vez se le ha dicho al idioma que existe una categoría de objetos como "cosas con brazos" es tan irrelevante para el ensamblaje ("sin tipo") como para Javascript ("dinámico"). Todo es una cuestión de integridad lógica, y el único error sería usar algo que no tuviera armas con ese método.

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

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

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

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

Considero que hay 3 tipos [SIC] de idiomas:

Sin tipo: solo el operador determina la interpretación del valor, y generalmente funciona en cualquier cosa. Ejemplos: ensamblador, BCPL

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

Tipo dinámico: 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 escritos dinámicamente son seguros, es decir, solo los operadores válidos pueden operar con valores. Pero lo mismo no es cierto para el lenguaje de tipo estático. Dependiendo de la potencia del tipo de sistema utilizado, algunos operadores pueden ser verificados solo en tiempo de ejecución, o 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 matriz fuera del límite no se verifican (C, C ++) o solo se verifican en tiempo de ejecución Además, algunos sistemas de tipos son tan débiles que la programación útil requiere sombreados de escape (conversiones en C y familia) para cambiar el tipo de expresiones en tiempo de compilación.

Todo esto lleva a afirmaciones absurdas, como que C ++ es más seguro que Python porque es (estáticamente tipado), mientras que la verdad es que Python es intrínsecamente seguro mientras puedes disparar tu pierna con C ++.

No soy un científico de la computación, pero me sorprendería que "sin tipo" se usara realmente como sinónimo de "tipo dinámico" en la comunidad de CS (al menos en publicaciones científicas) ya que, en mi opinión, esos dos términos describen conceptos diferentes. Un lenguaje de tipo dinámico 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 están escritas" en Javascript (lo cual es cierto). Pero eso no significa automáticamente que el idioma no esté tipificado (lo que sería falso).

De acuerdo con Brendan: el contexto lo es todo.

Mi toma:

Recuerdo estar confundido, alrededor del año 2004, porque surgieron discusiones sobre si Ruby no tenía tipo o si estaba escrito dinámicamente. Las personas de C / C ++ de la vieja escuela (de las cuales yo era uno) pensaban en el compilador y decían que Ruby no estaba tipificado.

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 es, whoops. Eso definitivamente no tiene tipo y es muy diferente de lo que se escribe dinámicamente.

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

Hoy, para los programadores practicantes, estamos tan acostumbrados a los lenguajes dinámicos, obviamente pensamos que sin tipo significa que no hay verificación de tipo de compilador o intérprete, 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 puede que ni siquiera sea significativo.

En cierto sentido profundo, nada puede ser sin tipo (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 se ocupa de los detalles de cómo se implementa un compilador o intérprete para un idioma determinado. Así que "sin tipo" es (probablemente, no lo sé) completamente sin sentido en ese contexto.