¿Cómo es que la mayoría de los Lisps y los Esquemas se escriben dinámicamente? ¿La tipificación estática no se combina con algunas de sus características comunes?¿Por qué la mayoría de los lenguajes de S-Expression se tipan dinámicamente?
El tipado y las expresiones s se pueden hacer para que funcionen juntas, consulte typed scheme.
En parte es una coincidencia histórica que los lenguajes s-expression se tipean dinámicamente. Estos lenguajes tienden a depender más de macros, y la facilidad de análisis y coincidencia de patrones en s-expressions hace que el procesamiento de macros sea mucho más fácil. La mayoría de las investigaciones sobre macros sofisticadas ocurren en lenguajes de expresión s.
Typed Hygienic Macros son difíciles.
Cuando Lisp se inventó en los años de 1958 a 1960, introdujo muchas funciones como lenguaje y como implementación (recolección de basura, compilador autohospedado, ...). Algunas características se heredaron (con algunas mejoras) de otros idiomas (procesamiento de listas, ...). El lenguaje implementó la computación con funciones. Las expresiones s eran más un detalle de implementación (en ese momento) que una función de idioma. Un sistema de tipo no era parte del lenguaje. Usar el lenguaje de manera interactiva también fue una característica de implementación temprana.
Los sistemas de tipo útil para lenguajes funcionales aún no se habían inventado en ese momento. Sin embargo, hasta el día de hoy también es relativamente difícil usar lenguajes estáticos de manera interactiva. Hay muchas implementaciones de lenguajes tipados estáticamente que también proporcionan alguna interfaz interactiva, pero en su mayoría no ofrecen el mismo nivel de soporte de uso interactivo que un sistema típico de Lisp. La programación en un sistema Lisp interactivo significa que muchas cosas se pueden cambiar sobre la marcha y podría ser problemático si los cambios de tipo debieran propagarse a través de programas completos y datos en un sistema Lisp interactivo. tenga en cuenta que algunos Schemers tienen una visión diferente sobre estas cosas. R6RS es principalmente un lenguaje por lotes generalmente no mucho en el espíritu de Lisp ...
Los lenguajes funcionales que luego se inventaron con sistemas de tipo estático también obtuvieron una sintaxis de no expresión, no ofrecieron soporte para macros o funciones relacionadas. más tarde, algunos de estos lenguajes/implementaciones usaron un preprocesador para extensiones sintácticas.
Interesante, ¿por qué dices que R6RS es principalmente un lenguaje por lotes? –
No hay semántica descrita en R6RS para el uso interactivo del idioma. por ejemplo, EVAL es una función de biblioteca y no está completamente especificada. Las implementaciones pueden intentar eludir eso, pero también parece que los autores de R6RS no estaban interesados en el uso interactivo. Entonces, no hay nada que hable de bibliotecas y REPL, por ejemplo. En general, estoy completamente decepcionado por la calidad del estándar R6RS, además de las limitaciones técnicas del lenguaje descrito. Espero que R7RS mejore. –
La tipificación estática es léxica, significa que toda la información acerca de los tipos se puede deducir de la lectura del código fuente sin evaluar ninguna expresión ni calcular ninguna cosa, siendo los condicionales los más importantes aquí. Un lenguaje estáticamente está diseñado para que esto suceda, un término mejor sería 'lexically typed', como en, un compilador puede probar al leer solo la fuente que no se producirán errores de tipo.
En el caso de lisp, esto es extrañamente diferente porque el código fuente de lisp en sí no es estático, lisp es homo-icónico, utiliza datos como código y puede, hasta cierto punto, editar dinámicamente su propia fuente de ejecución.
Lisp fue el primer lenguaje de tipado dinámico, y probablemente por esta razón, el código del programa ya no es léxico en Lisp.
Editar: una razón mucho más poderosa, en el caso del tipado estático, tendría que escribir listas. Puede tener tipos extremadamente complejos para cada lista que tenga en cuenta todos los elementos, solicitar que cada elemento tenga el mismo tipo y escribirlo como una lista de eso. La primera opción producirá un infierno con listas de listas. La última opción exige que el código fuente solo contenga el mismo tipo para cada dato, esto significa que ni siquiera puede construir expresiones, ya que una lista es, de todos modos, un tipo diferente de un entero.
Así que me atrevo a decir que es completamente imposible de realizar.
Es simplemente difícil, no imposible. Ver MetaML y MetaOCaml para contra-ejemplos. Y los idiomas de tipo dependiente pueden hacer esto también: ver los experimentos con evaluación parcial en Idris. –
Uno tiene que eliminar tanto que ya casi no se puede hablar de 'S-expression based'. Una idea central para las expresiones S es la función de aplicación, que hace que el código mismo sea dinámico, seguramente es imposible probar de forma estática la ausencia de errores de tipo. Mirando MetaML y MetaOCAML, no veo ningún indicio de que estén basados en la expresión S o sean homo-icónicos. – Zorf
El esquema mecanografiado no está tipado estáticamente, proporciona tipos como comprobación de errores. La tipificación estática se niega a compilar a menos que el compilador pueda probar que el programa está completamente seguro. El esquema mecanografiado todavía produce errores del tipo de tiempo de ejecución, en tipeo estático esto no es posible. – Zorf
@ Lajla, sí, aunque no dije que el esquema mecanografiado estaba escrito de forma estática. –
Typed Racket ** está ** estáticamente estátipo: la comprobación de tipo ocurre en tiempo de compilación. Si no pasa el contador de tipos de raqueta con tipo, se niega a continuar. En operaciones normales, una vez que se pasa el chequeo de tipo, Typed Racket aplicará optimizaciones (http://docs.racket-lang.org/ts-reference/Optimization_in_Typed_Racket.html) que no serían seguras sin las garantías de tipo conocidas en typechecking. – dyoo