usos para librerias lenguajes inteligencia imprimir importar funcionales español entornos ejemplos desarrollo como artificial haskell polymorphism generic-programming

para - imprimir en haskell



¿Por qué las bibliotecas estándar de Haskell no hacen más uso del polimorfismo? (4)

Estoy en el proceso de aprender Haskell, y las clases de tipos parecen ser una forma poderosa de hacer funciones polimórficas seguras para los tipos. Pero muchas de las funciones de Haskell Prelude no las usan. Más específicamente:

  • La mayoría de las funciones de lista no funcionan con otras estructuras de datos (por ejemplo, foldr y length solo se implementan para listas y no se pueden usar en arreglos).

  • Los módulos como Data.ByteString son inutilizables a menos que use la import qualified ya que incluyen funciones que tienen los mismos nombres que las funciones de Prelude.

Parece que estos dos problemas desaparecerían si la biblioteca estándar usara funciones genéricas con clases de tipo (por favor, avíseme si estoy totalmente equivocado con esto).

Tengo dos preguntas:

  1. ¿Hay razones técnicas o de diseño para que el Preludio sea así, o es solo por razones históricas?

  2. Mirando alrededor, parece que hay un par de bibliotecas (como Data.Foldable y, si no me equivoco, Scrap Your Boilerplate) que reemplazan las funciones estándar de Prelude con alternativas genéricas. ¿Hay planes para incorporar estas ideas en futuras versiones de Haskell?


  1. Si bien hay muchas cosas en la base, y específicamente Prelude, que son históricas, creo que cualquier generalización vería un montón de rechazo técnico. El problema principal es la velocidad: si tu función tiene una restricción de clase de tipo, entonces estarás pasando un diccionario para las funciones de clase de tipo y tal vez comas más espacio para la especialización.

  2. Algunas de las bibliotecas, como SYB, usan extensiones que no son parte de Haskell. La primera tarea sería formalizar y generar soporte para estas características. Mire los documentos de Haskell para ver a dónde va Haskell y cómo podría influir en ese camino.


Hay una muy buena razón pragmática de que Haskell "estándar" (Prelude + base + quizás algo más) no usa más polimorfismo:

Diseñar clases de tipo de uso general es difícil . Los buenos diseños para las clases que abstraen sobre tipos de contenedores como listas, matrices y "bytestrings" (personalmente no considero que Bytestring un contenedor) no están flotando alrededor de Haskell 2012. Hay algunos diseños, por ejemplo, Listlike y Edison, y varias personas han resuelto el problema, pero a excepción de Foldable y Traversable, nadie ha producido diseños atractivos.


La biblioteca base de Haskell solía ser más polimórfica: las comprensiones de listas utilizadas para cualquier mónada, map y ++ no se limitaban a la Lista, y quizás otras cosas.

Pero las personas en ese momento pensaron que llevó a confundir los mensajes de error para los principiantes y que las personas que no son principiantes pueden usar las versiones específicamente polimórficas.


Real World Haskell tiene algunas ideas sobre esto en el capítulo de Monad Transformers :

En un mundo ideal, ¿haríamos una ruptura con el pasado y cambiaríamos a Prelude para usar los tipos Traversable y Foldable? Probablemente no. Aprender Haskell ya es una aventura suficientemente estimulante para los recién llegados. Las abstracciones plegables y transitables son fáciles de aprender cuando ya entendemos los funtores y las mónadas, pero pondrían a los primeros en una dieta de abstracción demasiado pura. Para enseñar el idioma, es bueno que el mapa funcione en listas, no en funtores.