Crear una jerarquía de clases de widgets GUI es prácticamente un ejercicio estándar en programación orientada a objetos. Tienes algún tipo de resumen.Widget clase, con una subclase abstracta para widgets que pueden contener otros widgets, y luego tiene una profusión de clases abstractas adicionales para widgets que admiten visualización textual, widgets que son el foco de entrada, widgets que tienen un estado booleano, hasta el real Clases concretas como botones, controles deslizantes, barras de desplazamiento, casillas de verificación, etc.

Mi pregunta es: ¿Cuál es la mejor manera de hacer esto en Haskell?

Hay una serie de cosas que dificultan la construcción de una interfaz gráfica de usuario de Haskell, pero sonno parte de mi pregunta. Hacer I / O interactivo es un poco complicado en Haskell. Implementar una GUI casi siempre significa escribir un contenedor en una biblioteca C o C ++ de nivel extremadamente bajo. Y las personas que escriben envoltorios de este tipo tienden a copiar la API literalmente (probablemente, cualquiera que sepa que la biblioteca envuelta se sentirá como en casa). Estos problemas no me interesan por el momento. Estoy interesado puramente en la mejor manera de modelar el polimorfismo de subtipo en Haskell.

¿Qué tipo de propiedades querríamos de nuestra hipotética biblioteca de GUI? Bueno, queremos que sea posible agregar nuevos tipos de widgets en cualquier momento. (En otras palabras, un conjunto cerrado de posibles widgets no es bueno). Queremos minimizar la duplicación de código. (Existenmucho de tipos de widgets!) Lo ideal es que podamos estipular un tipo de widget específico cuando sea necesario, pero también poder manejar colecciones dealguna Tipo de widget si es necesario.

Todo lo anterior es, por supuesto, trivial en cualquier lenguaje OO que se respete a sí mismo. Pero, ¿cuál es la mejor manera de hacer esto en Haskell? Puedo pensar en varios enfoques, pero no estoy seguro de cuál sería "el mejor".