Sugerencias para una biblioteca GUI en Haskell [cerrado]

Como dice la propia Wiki de Haskell :

Hay una gran cantidad de bibliotecas GUI para Haskell. Lamentablemente, no existe uno estándar y todos están más o menos incompletos. En general, las carillas de bajo nivel van bien, pero son de bajo nivel. Las abstracciones de alto nivel son bastante experimentales. Existe la necesidad de una biblioteca GUI de nivel medio compatible.

Un profesor de mi universidad me pidió a mí y a otras tres especialidades en informática que consideraran trabajar en una biblioteca GUI para Haskell. Su idea inicial para el proyecto fue escribir una capa encima de OpenGL que imitara la biblioteca mórfica encontrada en Smalltalk ; sin embargo, esto es solo una sugerencia y definitivamente vale la pena considerar otro sistema.

Esto nos lleva a la pregunta real de varias partes.

1. ¿Para qué nivel de abstracción debe esforzarse nuestra biblioteca? El Wiki de Haskell parece indicar fuertemente que se preferiría una biblioteca GUI de nivel medio; sin embargo, una biblioteca de alto nivel aún sería bienvenida.
2. ¿Sobre qué debería construirse nuestra biblioteca? (Ej. OpenGL)
3. ¿Qué biblioteca GUI existente le gustaría ver que imita nuestra biblioteca (si existe) y por qué? (Ej. PyGame, Morphic, Swing, etc.)
4. ¿Qué características le gustaría que nuestra biblioteca implementara o evitara? Por ejemplo, las buenas personas en Gnome podrían argumentar que el botón minimizar es innecesario.
5. ¿Tienes alguna sugerencia general?
6. ¿Qué nombre inteligente le darías a esta biblioteca imaginaria? (Ej. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

Me gustaría ver una biblioteca que sea elegante y fácil de usar con Haskell. El resto son detalles técnicos que deberían servir para este propósito, no redefinirlo. Por lo tanto, mis $ 0.02.

No lo base en un conjunto de herramientas existente , como Qt o GTK o FLTK o ... - esto lo limitará severamente y probablemente le causará mucho más dolor que ganancias. PyQt es, erm, bastante divertido y artificial, y tanto Python como C ++ son lenguajes imperativos OO extremadamente flexibles. En el caso de Haskell, las cosas serían mucho más difíciles, supongo.

Depende solo de las primitivas gráficas más básicas , luego construya sobre eso. OpenGL es bueno, pero incluso algo más simple (solo 2D, por ejemplo, SDL) también funcionaría bien. Esto le dará la máxima flexibilidad y la máxima portabilidad. Ver Smalltalk / Morphic, Java / Swing, TCL / Tk.

Hazlo conceptualmente pequeño. Las GUI son difíciles como son, no es necesario agregar otro Everest para escalar. Haskell, espero, puede ayudar a hacer la cosa compacta y modular.

Para obtener puntos de bonificación, haz que se pueda pelar. Como mínimo, sepa cómo aplicar los colores del sistema (y solo los colores del sistema) para pintar todo su repertorio de controles, de modo que una aplicación creada con este kit de herramientas no sea una monstruosidad. Como máximo, sepa cómo hacer que Win32 / Gtk / Qt / Cocoa dibuje sus controles para que se vean completamente nativos. La skinnability básica es simple y lógica; lograr una apariencia nativa completa es bastante difícil.

Además, ejecute sin root y deje la administración de ventanas al sistema gráfico subyacente : X, Windows, lo que sea. No hacerlo desafiará la cordura de los usuarios y dificultará drásticamente la adopción.

Como de costumbre, 'haga que las cosas simples sean simples y que las cosas complejas sean posibles' + 'evite la tarpit de Turing donde todo es posible pero nada de interés es simple' + 'haga lo más simple posible pero no más simple'.

El nombre es lo menos importante. De todos los kits de herramientas de GUI populares, solo Qt tiene un nombre inteligente. Varios proyectos populares cambiaron de nombre, incluso en vuelo (Firefox, née Firebird). Tiene algo para nombrar, y lo nombrará.

¡Buena suerte!

Después de hablar con todos los estudiantes involucrados y dar a esta pregunta el tiempo suficiente para generar interés, creo que hemos llegado a un consenso sobre algunas de las preguntas clave en mi publicación original.

¿Para qué nivel de abstracción debe esforzarse nuestra biblioteca? El Wiki de Haskell parece indicar fuertemente que se preferiría una biblioteca GUI de nivel medio; sin embargo, una biblioteca de alto nivel aún sería bienvenida.

Decidimos apuntar a una biblioteca de nivel medio según la sugerencia de Haskell Wiki.

¿Sobre qué debería construirse nuestra biblioteca? (Ej. OpenGL)

Elegimos OpenGL debido a su popularidad y soporte. Utilizaremos los proyectos de envoltura GLUT o GLFW Haskell como base.

¿Qué biblioteca GUI existente le gustaría ver que imita nuestra biblioteca (si existe) y por qué? (Ej. PyGame, Morphic, Swing, etc.)

Elegimos Morphic después de un debate considerable entre este y PyGame. No consideramos QT o GTK ya que ambos ya tienen uno o más proyectos de biblioteca Haskell en desarrollo activo .

¿Qué nombre inteligente le darías a esta biblioteca imaginaria? (Ej. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

Esto todavía está en debate. Hemos decidido no considerar HAWT y en su lugar estamos viendo:

• CALIENTE - Haskell Opengl Toolkit
• HOG - Haskell Opengl Graphics (¡Haz que tu proyecto funcione con HOG!)
• Schön