2012-01-26 10 views
14

En una gran cantidad de documentación del módulo generado por el eglefino (por ejemplo Prelude), una pequeña caja en la parte superior derecha se puede ver, que contiene la portabilidad, la estabilidad y el mantenedor de información:¿Cómo se usan los módulos del módulo de Haddock Portabilidad, Estabilidad y Mantenedor?

An example package information box

De mirar el código fuente a este tipo de módulos y experimentación, he confirmado que esta información se genera a partir de líneas como las siguientes en la descripción del módulo:

-- Maintainer : [email protected] 
-- Stability : stable 
-- Portability : portable 

Hay varias cosas extrañas sobre este

:
  • Los campos única parecen funcionar en este orden - cualquier campo ponen fuera de servicio son simplemente tratar como parte de la descripción del módulo en sí. Esto a pesar del hecho de que el orden en el archivo de origen es el opuesto al del orden en la documentación generada.

  • No he podido encontrar ninguna documentación oficial de estos campos. Hay un Cabal package property llamado stability, cuyos valores de ejemplo coinciden con los valores que he visto en los campos de eglefino equivalentes, pero más allá de eso, no he encontrado nada.

Así: Cómo son estos campos destinados a ser utilizados, y se documentaron en cualquier lugar?

En particular, me gustaría saber:

  • La lista completa de los valores de uso común para Portability y Stability. This HaskellWiki page tiene una lista, pero me gustaría saber de dónde se originó esta lista.

  • Criterios para decidir si un módulo es portátil o no portátil. En particular, el paquete que me gustaría recibir las respuestas a estas preguntas, acme-strfry, es un enlace FFI a strfry, una función solo disponible en glibc. ¿El paquete no es portátil, porque solo funciona en sistemas glibc, o portátil, porque no usa extensiones de lenguaje Haskell? El uso común parece implicar lo último.

  • Por qué se requiere un orden específico de campos en el archivo fuente y por qué es el opuesto al orden en la documentación generada.

Respuesta

4

Oh, pensé que esos campos eran de la descripción del paquete cabal. No parecen estar documentados en absoluto en los documentos de Haddock. He encontrado esto, que en realidad no responde a su pregunta, pero:

http://trac.haskell.org/haddock/ticket/71

Así que si es de forma libre de todos modos, ¿por qué no escribir "no portátil (depende de glibc)"? Incluso he visto "portátil (depende de ghc)", lo cual es extraño. También me pregunto qué sucede con los módulos que no eran portátiles debido a la extensión no de Haskell98 Foo, después de que Foo se añadiera a Haskell 2010.

Tenga en cuenta que la documentación de Cabal a la que se vincula también dice que estabilidad es de forma libre. Por supuesto, incluso si haddock o cabal fueran a definir cuáles son los valores aceptables, aún le correspondería al mantenedor seleccionar subjetivamente uno.

Sobre el orden específico, probablemente debería simplemente preguntar en la lista de correo de eglefino, o consultar la fuente y presentar un error.

PD: strfry es una contribución invaluable para la comunidad Haskell, pero debe ser puro y portátil, ¿no crees?

+0

De hecho, actualmente estoy usando "no portátil (glibc solamente)", pero quería información sobre si este sería o no un uso correcto de el campo. – ehird

+0

Si bien los campos son de forma libre, el hecho de que la documentación de Cabal, la página de HaskellWiki y los valores que he visto aparezcan de un pequeño conjunto de valores (incluidos valores que no esperaría que nadie pensaran de forma independiente) , por ejemplo, "provisional") me hace pensar que los valores utilizados en la práctica provienen de un conjunto pequeño, incluso si ese conjunto no está escrito "oficialmente" en ninguna parte; sería bueno saber el origen del conjunto, por lo menos. Para el asunto del pedido, probablemente verifique la fuente o pregunte en la lista de correo pronto. – ehird

+0

P.S. Hacer 'strfry' puro sería bastante difícil, dada la dependencia en el estado RNG global :) – ehird

2

Ah sí, una de las características más oscuras y más crudas de Haddock.

Lo mejor que puedo decir, es solo un truco no documentado. No hay una razón sensata por la cual el orden de los campos debería importar, pero lo hace. La opción específica de formatear (es decir, como una forma especial dentro del comentario del módulo en lugar de como un bloque separado de algún tipo) tampoco es la mejor. Supongo que alguien quería agregar rápidamente esta característica un día, por lo que cortaron algo mínimo pero funcional, y lo dejaron así. (Sin molestarse en documentarlo)

Personalmente, simplemente no me molesto en absoluto con estos campos. La información está disponible en Cabal, así que no me molesto en duplicarla en Haddock también. Tal vez algún día Cabal pasará esta información a Haddock automáticamente ...

Cuestiones relacionadas