Me estoy enamorando lentamente de Erlang, y solo tengo un gran problema, GRANDE.Comprobación de tipos estáticos en erlang
Soy un gran admirador de idiomas como Standart ML y ocaml con su fuerte comprobación estática de tipos.
hay una forma agradable y limpia de introducir algunos tipos de comprobación de tipos estáticos en erlang. Estoy mirando las anotaciones -type y -spec.
¿Alguien tiene una buena solución?
¡He estado allí! Amo tanto OCaml como Erlang y los uso regularmente.
Cuando comencé a usar Erlang, tenía años de experiencia con OCaml. Me llevó varias semanas adaptarme al hecho de que no hay ningún registrador de tilde estático en el compilador. Pero después de eso, el dolor desapareció por completo.
Hasta cierto punto, pasar sin el typechecker es un ejercicio que vale la pena. Para mí, fue una experiencia esclarecedora y realmente me hizo un mejor programador.
Hay, sin embargo, un contador de estado estático externo para Erlang llamado Dializer. Me resulta muy útil. El problema es que debe llamarlo por separado y es lento. Ejecutarlo de vez en cuando (por ejemplo, antes de confirmar el código o como compilaciones automáticas) funciona muy bien. Nunca intenté ejecutarlo después de cada compilación, ya que sería una gran distracción esperar hasta que se complete.
verificación de la herramienta Dialyzer
el dializador es una herramienta de análisis estático que identifica las discrepancias de software tales como errores de tipo definidas, el código que se ha convertido muerto o inalcanzable debido a algún error de programación, pruebas innecesarias, etc. en módulos únicos Erlang o aplicaciones enteras (conjuntos de).
Yo sobre todo utilizar -spec y -type para fines de documentación: se escribe especificación con -spec, a continuación, comprobar con Typer y luego (después de añadir algo de información adicional en formato edoc) generar la documentación
eso es lo que terminé haciendo también :) –
A través de los años, Hubo algunos intentos de construir sistemas tipo en en la parte superior de Erlang. Uno de esos intentos ocurrió en 1997, dirigido por Simon Marlow, uno de los principales desarrolladores del compilador Haskell de Glasgow, y Philip Wadler, que trabajó en el diseño de Haskell y ha contribuido a la teoría detrás de las mónadas (Lea el documento sobre dicho tipo sistema). Joe Armstrong comentó más tarde en el periódico:
Un día Phil me llamó por teléfono y anunció que a) Erlang necesitaba un sistema de tipo, b) había escrito un pequeño prototipo de un sistema tipo yc) él tenía un año de sabático y que iba a escribir un sistema de tipo de Erlang y “estábamos nos interesa?” respuesta - “Sí.”
Phil Wadler y Simon Marlow trabajaron en un sistema de tipo durante más de un año y los resultados fueron publicados en [20] Los resultados del proyecto fueron algo decepcionantes .Para empezar, solo un subconjunto del lenguaje era verificable por tipo, la principal omisión es la falta de tipos de proceso y de mensajes interproceso de verificación de tipo.
Puede explicar por qué ir sin typechecker fue esclarecedor? ¿Te vuelves para pensar que los typecheckers son inútiles en tu experiencia? – mljrg
Existen muchas aplicaciones en las que los typecheckers son tremendamente útiles. Y funcionan como magia en idiomas como OCaml. Para mí, un efecto secundario de confiar siempre en ellos fue que la parte de mi cerebro no estaba prestando atención a un aspecto significativo de alto nivel de un programa. Se convierte en algo así como un punto ciego y prefiero mantener la plena conciencia y concentración del programa que estoy escribiendo. Dicho esto, me gustaría que hubiese un mejor typechecker opcional en Erlang. No se puede vencer a los revisores de tipos para la refactorización y la colaboración, ya que es imposible mantener el mismo enfoque con todo el código en todo momento. – alavrik