Sistema de módulos para lenguaje OOP

Estoy diseñando un lenguaje de programación OO simple.

Está estáticamente escrito, compilado y ejecutado por una VM, similar a Java.

La diferencia es que no quiero tener un énfasis tan fuerte en OOP. El código en sí se parecerá principalmente a C ++ (clases, funciones y variables permitidas en el alcance del archivo).

Una de las cosas que necesito tener es un sistema de módulos. Tengo lo siguiente resuelto:

Cada archivo es un módulo (una vez compilado), como Python
Los programadores deben importar un módulo con la importpalabra clave, lo que hace que el compilador busque módulos en directorios estándar y en el directorio de archivos (la VM también tiene que hacer esto en tiempo de ejecución)

Y ahora no tengo idea de cómo debo introducir el concepto de submódulos y jerarquía de módulos.

Una opción, por ejemplo, es depender de la jerarquía del directorio, por lo que import engine.graphics.rendereresperaría encontrar un directorio llamado "motor" en el directorio de trabajo, y dentro de un directorio llamado "gráficos", con un módulo llamado "renderizador".

¿Cuáles son los inconvenientes de tal diseño? ¿Me estoy perdiendo algo?

design programming-languages object-oriented modules virtual-machine-languages Aber Kled
fuente

Bueno, no sería el primero. Tanto Rust como OCaml tratan implícitamente el código en un archivo como parte de un módulo con el mismo nombre que el archivo. Parece funcionar bastante bien allí.

KChaloux 01 de

Y Haskell. Sin embargo, si está haciendo OOP de todos modos, le recomiendo que considere los "Módulos son objetos especiales" de Scala. ¿También tiene intención de admitir módulos de primera clase? Si es así, existe una ambigüedad entre foo.barser foo / bar.file o algún módulo foocon el miembro (también un módulo) bar. Algo a tener en cuenta

Daniel Gratzer

¿Cómo planeas manejar las versiones? Muchos idiomas no lo hacen en absoluto, pero es mejor que no cometas ese error por adelantado.

Donal Fellows

@DonalFellows ¿Quieres elaborar? ¿Cómo es la responsabilidad del idioma manejar versiones? Pero de todos modos, tenía la intención de presentar @annotationspara incrustar dicha información.

Aber Kled

@AberKled: No creo que el problema sea tanto que el lenguaje sea responsable de "manejar las versiones", como asegurarse de que si Fred tiene una versión del módulo X cuando escribe un módulo Y que funcione con él, y Joe tenga un diferente versión de X cuando escribe el módulo Z que funciona con él, luego, en ausencia de diferencias de comportamiento irresolubles entre las diferentes versiones de X, debería ser posible usar Y y Z juntos sin tener que volver a compilar.

supercat

Respuestas:

Eche un vistazo a la jerarquía / organización de paquetes / módulos de Python, y especialmente en el aspecto histórico, las principales incorporaciones a lo largo de los años, lo más importante, las últimas. Probablemente, no tiene sentido inventar la rueda.

No sé qué tan lejos quieres llegar con tu idioma, por ej.

¿Desea que el bytecode de módulos se lea desde zip?
¿Cómo se separan los módulos / bibliotecas para diferentes versiones de intérpretes?
¿Planeas hacer que parezca inútil con distros?
No olvide la facilidad de distribución propia del lenguaje (piense en distutils / pypi: cada plataforma / lenguaje tiene su propia, no siempre buena)

Supongo que Java puede ser otro ejemplo interesante. Las cosas también se pueden aprender de la manera de Erlang (por ejemplo, /programming/2968914/code-hot-swapping-in-erlang ).

Hay una gran cantidad de problemas de diseño (algunos mencionados anteriormente) si planea ver su lenguaje de programación convencional algún día. Afortunadamente, hay excelentes ejemplos por ahí.

Algunas direcciones del lenguaje de programación módulo / paquete / diseño del sistema de biblioteca deben abordar:

código intuitivo para escribir y usar el módulo
objetos de módulo / paquete en el código
capacidades de introspección de módulo / paquete
encapsulación de módulo / paquete (¿cómo ocultar detalles innecesarios?)
uso de interfaces / archivos de encabezado?
sistema de despacho fino, que pueden utilizar tanto las utilidades de distribución propias del lenguaje como las utilidades de nivel de sistema (evite el "infierno de DLL")
lugares de almacenamiento para módulos compilados en bytes
sistema de configuración, que automatiza la compilación tanto de módulos "puros" como de módulos / dependencias
lugar canónico de código compilado, pruebas, documentación, activos en su módulo

Roman Susi
fuente

esta publicación es bastante difícil de leer (muro de texto). ¿Te importaría editarlo en una mejor forma?

mosquito el

" Hay un montón de problemas de diseño si planeas ver tu lenguaje de programación convencional algún día " . No lo hago. Pero aún así agradecería si me

contaras

@gnat Gracias por señalarlo. Con suerte mejor ahora.

Roman Susi

@AberKled He intentado agregar algunos. Pero como dije en la respuesta, eche un vistazo a la historia del desarrollo de algún lenguaje convencional, mejor si es impulsado por las necesidades de la comunidad de programación en lugar de los puristas / elitistas, para aprender lecciones de los errores antes de cometer el suyo. Por supuesto, no olvide los principales objetivos de diseño para su idioma.

Roman Susi

En primer lugar, supongamos que asigna su modelo de espacio de nombres a otro espacio de nombres, como el sistema de archivos, como sugirió. En segundo lugar, supongo que los módulos pueden importar otros módulos. En otras palabras, bien engine.graphics.rendererpodría contener una línea como import circle.arc. Eso plantea dos cuestiones:

¿Dónde buscaría la VM circle.arc? De acuerdo con el sistema de archivos mappimg mencionado, debería haber un directorio como /etc/mylang/modules/circle/arc (que /etc/mylang/moduleses la raíz de la estructura de su módulo) .
¿Cómo haría referencia una aplicación circle.arc: importing circle.arco engine.graphics.render.circle.arc? El primero "estropearía" (si no arruina) la jerarquía, porque circle.arces claramente un submódulo de engine.graphics.renderer, y el segundo implicaría que debería haber un /etc/mylang/modules/engine/graphics/renderer/circle/arcen su sistema de archivos, colocándolo circle.arcen dos ubicaciones simultáneamente.

Habiendo dicho eso, y si decides seguir el enfoque del espacio de nombres, mapearlo al sistema de archivos me parece demasiado restrictivo. Creo que los módulos pueden residir en todo tipo de lugares (incluso archivos zip, como ya se mencionó, incluso URL). La VM comenzaría buscando una entrada en algún tipo de índice (tal vez un archivo de configuración) que mapearía el espacio de nombres a las ubicaciones reales del módulo.

geomagas
fuente

Probablemente te están rechazando porque realmente no estás respondiendo bien la pregunta específica del OP. Si su comentario no puede transmitir lo que quiere decir, entonces probablemente necesite tener una conversación más amplia con el OP sin conexión. Nuestra sala de chat es un gran lugar para hacer esto.

maple_shaft

@maple_shaft: ¿Qué quieres decir? ¿No es la pregunta "¿Cuáles son los inconvenientes de tal diseño?" ¿No estoy dejando suficientemente claro que mis puntos son posibles inconvenientes para la arquitectura de módulo sugerida por el OP? La razón por la que nunca pregunté por qué me rechazaron es que vengo de StackOverflow, donde la gente lo hace todo el tiempo sin preocuparse por dejar un comentario al respecto, lo cual es frustrante y, lo que es más importante, no constructivo , pero estoy acostumbrado a Sin embargo, y cansado de pedir una explicación.

geomagas

Usted admite que no tiene la intención de responder la pregunta y que está más o menos aclarando sus pensamientos sobre el ejemplo que proporcionó sobre qué hacer con el módulo Renderer. La pregunta realmente es más abstracta que eso y creo que necesita una respuesta más amplia. Estaba brindando una explicación para su beneficio porque creo que plantea buenos puntos y tiene buenas intenciones, pero en realidad no aborda las partes clave de la pregunta.

maple_shaft

Bueno, si la primera oración fue el problema, la eliminé, ya que de todos modos no estaba de acuerdo con el resto de la respuesta, lo que significa que, aunque comencé como "pensamientos", terminó abordando la pregunta real. En cuanto a que la pregunta es más abstracta, creo que no, ya que se expresa de una manera muy específica. Si me equivoco, espero que el OP especifique qué es lo que él implicó pero no expresó en palabras. Sé que su comentario fue para ayudar, a diferencia del comportamiento anónimo de Downvoter , y lo agradezco. Realmente lo hago

geomagas