He leído que el sistema de tipos de Scala se ve debilitado por la interoperabilidad de Java y, por lo tanto, no puede realizar algunos de los mismos poderes que el sistema de tipos de Haskell. ¿Es esto cierto? ¿Es la debilidad debido al borrado de tipo, o estoy equivocado en todos los sentidos? ¿Es esta diferencia la razón por la que Scala no tiene clases de tipos?Desventajas del sistema de tipo Scala versus Haskell?
Respuesta
La gran diferencia es que Scala no tiene inferencia de tipo global Hindley-Milner y en su lugar usa una forma de inferencia de tipo local, que requiere especificar tipos para parámetros de método y el tipo de retorno para funciones sobrecargadas o recursivas.
Esto no está dirigido por el borrado de tipos ni por otros requisitos de la JVM. Todas las posibles dificultades aquí se pueden superar, y han sido, simplemente considere Jaskell - http://docs.codehaus.org/display/JASKELL/Home
La inferencia H-M no funciona en un contexto orientado a objetos. Específicamente, cuando se utiliza el polimorfismo de tipo (en oposición al polimorfismo ad-hoc de las clases de tipo). Esto es crucial para una fuerte interoperabilidad con otras bibliotecas Java, y (en menor medida) para obtener la mejor optimización posible de la JVM.
No es realmente válido decir que Haskell o Scala tienen un sistema de tipo más fuerte, solo que son diferentes. Ambos idiomas están empujando los límites de la programación basada en tipos en diferentes direcciones, y cada idioma tiene fortalezas únicas que son difíciles de duplicar en el otro.
El Capítulo 16 muestra los tipos de datos y la coincidencia de patrones de Scala desarrollando un sistema de inferencia de tipo en el estilo H/M http: //www.scala -lang.org/docu/files/ScalaByExample.pdf – oluies
"La inferencia HM no funciona en un contexto orientado a objetos". Pero F # implementa H-M y tiene un lado orientado a objetos. –
@Mauricio: Sí, y OCaml es un ejemplo de contador aún mejor porque infiere tipos de clase ... –
Scala no tiene rank-n types, aunque puede ser posible work around this limitation en ciertos casos.
En una nota relacionada, tampoco admite la impredicabilidad. –
Otro punto interesante a considerar es que Scala admite directamente el estilo OO clásico. Lo que significa que hay subtipo relaciones (por ejemplo, List es una subclase de Seq). Y esto hace que la inferencia de tipo sea más complicada. Agregue a esto el hecho de que puede mezclar rasgos en Scala, lo que significa que un tipo dado puede tener múltiples relaciones de supertipo (haciéndolo aún más complicado)
Solo tengo poca experiencia con Haskell, pero lo más obvio es que tenga en cuenta que el tipo de sistema Scala diferente de Haskell es la inferencia de tipo.
En Scala, no hay ningún tipo de inferencia global, debe explícitamente le dice al tipo de argumentos de la función.
Por ejemplo, en la Scala tiene que escribir esto:
def add (x: Int, y: Int) = x + y
en lugar de
add x y = x + y
Esto puede causar problemas cuando se necesita versión genérica de la función de complemento que funciona con todas las clases de tipo tiene el método "+" Hay una solución para esto, pero se volverá más detallada.
Pero en el uso real, encontré que el sistema de tipos de Scala es lo suficientemente potente para el uso diario, y casi nunca uso esas soluciones genéricas, tal vez esto es porque vengo del mundo de Java.
y la limitación de declare explícitamente el tipo de argumentos no es necesario una mala cosa, es necesario documentar todos modos.
sistema de tipos de Scala es diferente de Haskell, aunque los conceptos de Scala a veces se inspiran directamente en los puntos fuertes de Haskell y su conocimiento de la comunidad de investigadores y profesionales.
Por supuesto, que se ejecuta en una máquina virtual no esté destinada principalmente para la programación funcional en primer lugar crea algunos problemas de compatibilidad con los lenguajes existentes dirigidas a esta plataforma. Como la mayoría de los razonamientos sobre tipos ocurren en tiempo de compilación, las limitaciones de Java (como lenguaje y como plataforma) en tiempo de ejecución no son motivo de preocupación (excepto Type Erasure, aunque este error parece hacer la integración en el El ecosistema de Java es más transparente).
Por lo que yo sé el único "compromiso" en el nivel de sistema de tipos con Java es una sintaxis especial para manejar tipos de primas. Si bien Scala ni siquiera permite los tipos crudos, acepta archivos de clase Java más antiguos con ese error. Quizás haya visto código como List[_]
(o el equivalente más largo List[T] forSome { type T }
). Esta es una característica de compatibilidad con Java, pero también se trata como un tipo existencial internamente y no debilita el sistema de tipos.
sistema de tipos de Scala hace de soporte type classes, aunque de un modo más detallado de lo Haskell.Sugiero leer este artículo, que podría crear una impresión diferente sobre la fortaleza relativa del sistema de tipos de Scala (la tabla de la página 17 sirve como una buena lista de conceptos de sistemas de tipo muy potentes).
No necesariamente relacionado con la potencia del sistema de tipo es el enfoque que utilizan los compiladores de Scala y Haskell para inferir tipos, aunque tiene cierto impacto en la forma en que las personas escriben el código. Tener un poderoso algoritmo de inferencia de tipo puede hacer que valga la pena escribir un código más abstracto (usted puede decidir si eso es algo bueno en todos los casos).
Al final, el sistema de tipos de Scala y Haskell está impulsado por el deseo de proporcionar a sus usuarios las mejores herramientas para resolver sus problemas, pero han tomado diferentes caminos para alcanzar ese objetivo.
+1 para la mención de esa tabla. –
tipos existenciales no son lo mismo que tipos crudos. Por ejemplo, List [_] no se considera un tipo igual a otra lista [_] –
Bueno, ¿son Turing reducibles?
la página de Oleg Kiselyov Ver http://okmij.org/ftp/ ... Se puede implementar el cálculo lambda en el sistema de tipos de Haskell. Si Scala puede hacer eso, entonces, en cierto sentido, el sistema de tipos de Haskell y el sistema de tipos de Scala calculan los mismos tipos. Las preguntas son: ¿Qué tan natural es uno sobre el otro? ¿Qué tan elegante es uno sobre el otro?
- 1. Haskell tipo matices del sistema
- 2. Ventajas del sistema de tipo de Scala
- 3. Ejecutando un comando del sistema en Haskell
- 4. Haskell Scala interoperabilidad
- 5. Scala composición del tipo de tupla
- 6. ¿Cómo obtener la hora del sistema en Haskell usando Data.Time.Clock?
- 7. lectura de entrada de un comando del sistema en Haskell
- 8. ¿Cuáles son las diferencias y similitudes de los sistemas de tipo Scala y Haskell?
- 9. Desventajas del framework cakePHP
- 10. Comparación de Scala (último 2.10) versus Groovy ++ (último 0.9.1?)
- 11. ¿Qué hace que el sistema de tipos de Haskell sea más "potente" que los sistemas de otros idiomas?
- 12. Desventajas del uso de Basic4Android?
- 13. Sistema de tipo Erlang
- 14. desventajas del patrón de diseño del generador
- 15. zend-framework versus Kohana versus Symfony
- 16. Expedición de comandos del sistema nativo en Scala
- 17. Tipos abstractos versus parámetros de tipo
- 18. Recursos de programación tipo Scala
- 19. Haskell listó tipo
- 20. Scala: seleccionando la función return Option versus PartialFunction
- 21. Scala Tipo de retorno
- 22. ¿Se puede implementar esta funcionalidad con el sistema de tipos de Haskell?
- 23. Haskell tipo sinónimo
- 24. Haskell "no" tipo restricción
- 25. parametrizado tipo de datos en Scala
- 26. Haskell: clases tipo de pregunta
- 27. tipo Haskell vs. newtype con respecto al tipo de seguridad
- 28. Unidad Scala tipo
- 29. Scala equivalente a las mónadas de Haskell
- 30. Eager versus Lazy Haskell. Listas infinitas posibles en idiomas impacientes?
Le recomendamos que lea esto. http://lambda-the-ultimate.org/taxonomy/term/32 –
Estoy bastante seguro de que Haskell tiene al menos tanta borradura de tipo como Scala, por lo que eso vale. –