scala - Codificación de módulos ML estándar en OO

oop module

Question

El sistema de módulos ML se erige como una marca de agua en el apoyo del lenguaje de programación para la abstracción de datos. Sin embargo, superficialmente, parece que puede codificarse fácilmente en un lenguaje orientado a objetos que admite miembros de tipo abstracto. Por ejemplo, podemos codificar los elementos del sistema de módulos SML en Scala de la siguiente manera:

• Firmas SML: rasgos de Scala sin miembros concretos
• Estructuras SML con firmas dadas: objetos Scala que extienden rasgos dados
• Funtores SML parametrizados por firmas dadas: Clases de Scala que toman objetos que extienden rasgos dados como argumentos de constructor

¿Hay alguna característica importante que una codificación se pierda? ¿Algo que pueda expresarse en módulos SML que la codificación no pueda expresar? ¿Alguna garantía que SML haga que esta codificación no sea capaz de hacer?

Answer 1

Hay algunas diferencias fundamentales que no puedes superar fácilmente:

• Las firmas ML son tipos estructurales, los rasgos de Scala son nominales: una firma ML puede ser igualada por cualquier módulo apropiado después del hecho, para los objetos Scala usted necesita declarar la relación en el momento de la definición. Del mismo modo, la subtipificación entre las firmas ML es completamente estructural. Los refinamientos de Scala están más cerca de los tipos estructurales, pero tienen algunas limitaciones bastante severas (p. Ej., No pueden hacer referencia a sus propias definiciones de tipos locales, ni contienen referencias gratuitas a tipos abstractos fuera de su alcance).

• Las firmas ML pueden componerse estructuralmente usando include y where . La firma resultante es equivalente a la expansión en línea de la respectiva expresión de firma o ecuación de tipo. La composición mixina de Scala, si bien es más poderosa en muchos sentidos, también es nominal y crea un tipo desigual. Incluso el orden de composición importa para la equivalencia de tipo.

• Los funtores ML se parametrizan por estructuras, y por tanto por ambos tipos y valores, las clases genéricas de Scala solo se parametrizan por tipos. Para codificar un functor, necesitaría convertirlo en una función genérica, que toma los tipos y los valores por separado. En general, esta transformación, llamada división de fase en la literatura del módulo ML, no puede limitarse a solo definiciones y usos de funtores, porque en sus sitios de llamada debe aplicarse recursivamente a argumentos de estructura anidados; en última instancia, esto requiere que todas las estructuras estén consistentemente divididas en fases, lo cual no es un estilo que desee programar manualmente. (Tampoco es posible asignar funtores a funciones simples en Scala, ya que las funciones no pueden expresar las dependencias de tipo necesarias entre los tipos de parámetro y resultado. Editar: desde 2.10, Scala tiene soporte para métodos dependientes, que pueden codificar algunos ejemplos del primer orden de SML funtores generativos, aunque no parece posible en el caso general.)

• ML tiene una teoría general de refinación y propagación de información de tipo "translúcido". Scala usa una teoría ecuacional más débil de tipos "dependientes de ruta", donde los caminos denotan objetos. De esta forma, Scala intercambia las equivalencias de tipo más expresivas de ML por la capacidad de usar objetos (con miembros de tipo) como valores de primera clase. No puede tener ambas cosas fácilmente sin tener que enfrentarse rápidamente con problemas de decidabilidad o solidez.

• Edición: ML puede expresar naturalmente constructores de tipo abstracto (es decir, tipos de tipo superior), que a menudo surgen con funtores. Para Scala, los tipos superiores deben activarse explícitamente, lo que es más desafiante para su sistema de tipos, y aparentemente conducen a una verificación de tipo indecidible.

Las diferencias se vuelven aún más interesantes cuando se mueve más allá de SML, a módulos de orden superior, de primera clase o recursivos. Discutimos brevemente algunos problemas en la Sección 10.1 de nuestro documento MixML .