"HList moderno"?

El HList package se basó en lo que es ahora antigua Tecnología Haskell. La simple pregunta es: dadas todas las maravillosas características nuevas de los últimos 8 años del desarrollo de Haskell/GHC, ¿se podría construir una HList "moderna" de manera muy diferente? Me doy cuenta de que la respuesta aquí podría ser no, que para el caso particular de HList, la tecnología utilizada sigue produciendo la solución más elegante."HList moderno"?

He leído muchos de los artículos documentados en la página extensible records, el único competidor real (es decir, uno que se implementa como una biblioteca disponible en hackage) es el records package. ¿O faltan enlaces de extensible records?

Fuente

2012-08-22 Jacques Carette

La pregunta para cualquiera de estos paquetes es el alcance de sus objetivos. HList es en realidad 5 implementaciones diferentes de etiquetas, dos de tipo igualdad, dos de tipo fundido, dos de Record/RecordP, y la opción Variant vs TIC. Todos son similares, pero son intercambios diferentes de facilidad de uso, portabilidad y extensiones utilizadas.

Las características más nuevas de GHC (GADT, tipos asociados, tipos de restricciones, tipos polimórficos, tipos de singleton) pueden permitir intercambios ligeramente diferentes. En particular, los tipos singleton pueden permitir mejores etiquetas, y los tipos polimórficos pueden permitir una Typeable/Data/Generics más elegante.

El paquete de "registros" se vincula a depende del paquete de "tipo" que dice:.

"Haskell no tiene soporte para subkinds y polimorfismo subkind Sin embargo, este paquete se puede utilizar para emular subkinds de tipo * y variables de subgénero ".

Pero esto ya no es cierto gracias a la promoción del tipo de datos a los tipos en las nuevas versiones de GHC. Entonces, este paquete de enero de 2012 puede ser algo obsoleto ahora.

En cuanto a los registros, tal vez un nuevo sistema se basará en la última ronda de lentes polimórficas: lens y/o lens-family.

Fuente

2012-08-22 20:22:07

Esta mañana estuve discutiendo la relación entre lentes y registros extensibles con Russell (O'Connor), y no está claro. Las lentes son geniales para abstraer la obtención/conjunto de un solo campo en un agregado, pero menos bueno para representar el agregado en sí. En cualquier caso, parece que debería seguir con HList (por ahora), y luego tratar de encontrar cuál de los trillizos de la variante que debería elegir para tratar el problema en cuestión (que es la traducción de algún código O'Caml que utiliza polimórficos variantes AND tipos de fila Y Functors en Haskell). –

Hace poco hice una cosa inspirada en HList: dado un tipo de coproducto indexado (TIP) y {handler para uno de los casos} devuelve {el resultado del controlador} o {el TIP con un tipo más pequeño} . El encadenamiento de manipuladores junto con> => reduce el TIP caso por caso. En ese momento pensé que era una especie de simulación de variantes polimórficas que coincidían. –

Respuesta

Cuestiones relacionadas